对于大多数开发者而言，webhook 起初只是一个数据接收的问题：暴露一个 HTTP POST 端点、验证签名、解析 JSON、返回 200 OK。然而，当你的 SaaS 发展壮大后，高级用户会提出反向需求——他们不想每分钟轮询你的 REST API 来确认发票是否已支付，而是希望你近乎实时地将事件推送到他们的服务器。请在此处阅读完整文章：https://instawebhook.com/blog/building-a-custom-webhook-provider-api-design-lessons-from-stripe-and-github

一旦你成为事件发送方，你就在做分布式系统的工作。你要向自己无法控制的服务器发出出站 HTTP 请求，而这些服务器可能会超时、断开连接、返回 500 错误、因部署失误而使用了错误的密钥，或者整个周末都不可用。一个粗心的重试循环可能会压垮正在恢复的客户服务，或堵塞你自己的队列。此外，由于你的数据包通过公共互联网传输，你的客户需要一种方法来证明请求确实来自你。

有两个服务商设定了大多数开发者熟悉的参考标准：

  • Stripe 拥有最成熟的 webhook 系统之一：一致的事件信封、带时间戳的签名、持续多天的重试，以及带有手动重发功能的投递日志。
  • GitHub 展示了一种更简洁的设计：元数据放在请求头，裸资源放在请求体，没有自动重试，且重发窗口很短。

它们做出了不同的权衡，而这些差异具有启发性。第三个参考标准是开源的 Standard Webhooks 规范，它将常见实践提炼为一套统一的约定，在你需要做出选择时是一个很好的裁决工具。