Webhook是“用户定义的 HTTP 回调”：
- 它们通常由某些事件触发（不是通常用用户操作人为触发的），例如将代码推送到存储库或发布到博客的评论；
- 当该事件发生时，源站点就向为 webhook 配置的 URL 发出 HTTP 请求。用户可以将它们配置为导致一个站点上的事件调用另一个站点上的行为。
从技术上讲，当特定事件发生时，Webhook 就是一个由系统触发的 POST 请求。下图显示了Webhook在事件触发如何发出的一个简单的 POST 请求 ：
当客户端（原始网站或应用程序）向第三方用户的服务器发出 webhook 调用时，传入的 POST 请求应进行身份验证以避免欺骗攻击。使用不同的技术来验证客户端：
- 接收端点可以选择保留一个已知来源的IP 地址列表，这些来源的请求将被接受。
- HTTP基本身份验证可用于对客户端进行身份验证。
- Webhook 可以包含有关事件类型的信息，以及用于验证 Webhook的共享机密或数字签名。
- 一个HMAC签名可以被包括作为一个HTTP标头。GitHub 和 Stripe 使用这种技术。
- Facebook 使用SHA-1签署他们的请求。
- 建立连接时可以使用相互 TLS 身份验证。然后端点（服务器）可以验证客户端的证书。
相关软件介绍：
Hook Slinger 一种用于发送、重试和管理 webhook的开源通用服务，让您可以发送、重试和管理由Webhook事件触发的 POST 请求，它提供了一个完全独立的 docker 镜像，易于编排、管理和扩展。
有一些因素使得管理 webhook 的生命周期变得棘手，例如：
- 处理发送端和接收端的系统故障。
- 管理 HTTP 超时。
- 处理异常并重试请求，而不会让接收者不堪重负。
- 避免发送端的重试循环。
- 监控并提供手动干预的范围。
- 快速扩展系统；垂直或水平。
- 将 Webhook 管理逻辑与主要应用程序逻辑分离。
正确处理这些问题可能很麻烦；尤其是当发送 webhooks 只是应用程序的另一小部分时，您只希望它能够正常工作，而不必每次都处理所有繁琐的细节。Hook Slinger 旨在缓解这一痛点。
Hook Slinger 公开了一个端点，您可以在其中发布您的 webhook 负载、目标 URL、身份验证详细信息，它会在后台为您异步发出 POST 请求。在幕后，该服务使用：
- FastAPI提供Uvicorn驱动的ASGI服务器。
- Redis和RQ用于实现消息队列，提供异步和健壮的故障处理机制。
- Rqmonitor提供一个仪表板，用于监控 webhooks 的状态并手动重试失败的作业。
- Rich：使容器日志丰富多彩，更人性化。