为什么你的 API 需要 Webhook

「软件正在吞噬世界」，现在 API 在吞噬软件。随着 API 无处不在，开发者要求实时事件数据。实时更新的常见方案是轮询（polling），但它弊端明显——正如 Zapier 所说：「反复打同一端点找新数据，我们不喜欢，厂商不喜欢，用户也不喜欢。」

于是 Webhook 登场：它让 API 使用者在特定事件发生时收到通知，免去不断发请求查更新的麻烦。Stripe、SendGrid 等头部厂商都有完善且文档齐全的 Webhook。

Webhook 系统通常比轮询省资源得多，对提供方与消费者都如此。例如 1000 个用户每 5 秒轮询一次，API 每秒要扛最多 1000 请求；而 Zapier 估计仅 1.5% 轮询请求能查到更新。

换成 Webhook，你每秒只需发约 15 个响应，而用户完全不必发请求——资源消耗不到轮询方案的 1%。

Webhook 体验更好。强迫用户不断轮询，等于让他们自己维护并比对状态。打个比方：轮询像孩子不停问「到了吗」，父母反复答「没」；而 Webhook 像孩子安静看书，父母安心开车——事件发生时再通知。

若用户要实时更新，轮询得每秒甚至更频繁发请求，既增负载又增运维复杂度。一旦触发 API 限流就会被拦；为不超限而降低频率，又会导致数据陈旧、满意度下降乃至流失。Webhook 在事件发生的瞬间推送，避开这一难题。

Stripe、Plaid 等主流厂商都有完善 Webhook，渐成标配，开发者已习惯这种简单可消费的 pattern。Wufoo（现 SurveyMonkey）调研显示，82% 的开发者偏好 Webhook 而非轮询。

Zapier、IFTTT、Make 等自动化平台都同时支持轮询与 Webhook。接入它们好处多多：对接市场上 3000+ 应用、持续兼容新应用、把你的 API 曝光给 350 万+ 用户，并用无代码方式把用户群扩展到开发者之外。

某些场景轮询更优（更新比轮询间隔还频繁时，批量拿更省；不需要实时时也 OK）。阻碍多数厂商提供 Webhook 的主因是规模化实现难：用户端点不可靠需要自动重试、要监控投递并在端点坏了时通知客户；还要防范 SSRF、重放攻击等漏洞；需要让用户能认证事件确来自你的 API；最好再有调试与监控的 UI。连资金充裕的 Lob 也专门重构了 Webhook 系统来简化设计。

Webhook 正成为 API 的必备特性：提供实时更新高效、开发者体验好、还能通过 Zapier/Make 等无代码平台获得大量集成。尽管规模化实现不易，但已有开源与托管方案能让你轻松提供优秀的 Webhook 体验。