什么是 Webhook
"Webhook" 的名字源于它的功能，顾名思义 Web 代表网页，Hook 代表钩子 。当一件事发生时，服务端会将相关信息发送给你设定好的 URL，这个 URL 就像一个钩子，抓取到了数据后，再将它传递给客户端进行处理。这种机制可以用于信息主动推送的场景，例如收到新告警通知、新邮件或订单时即刻得到通知并做出相应处理。
Webhook 本质上是一种事件驱动的 HTTP 回调机制。参与这个机制的有两方：
- 消费方：开发一个可以接收请求的 Web 服务，并为这个服务暴露一个接口，当接口收到请求时，解析事件信息，并触发相关业务流程。
- 服务方：定义一些事件或条件，当这些事件/条件触发时，向消费方暴露的接口 URL 发送请求，并且在请求中携带一些跟这个事件相关的信息。
Webhook 通常会使用在如下场景中：
- 持续集成与代码部署（CI/CD） 代码仓库在有新提交或构建完成后，通过 Webhook 触发测试、构建和部署流水线。
- 支付和电商系统回调 一个订单支付完成后，通过 Webhook 通知电商、物流、邮寄等系统执行后续操作。
- 业务监控与报警 对关键业务指标进行监控，异常时通过 Webhook 将事件通知推送到 IM 系统（企业微信，飞书，钉钉等等），实现快速响应。
以业务监控与报警使用的场景为例，整个使用的过程如下：
- 小 o 在 Slack 上创建一个叫 "预警助手" 的机器人， 并获得了一个Webhook URL:
https://hooks.slack.com/services/T0001/B00001/XXXXX - 小 o 在监控告警系统记录下了这个 Webhook URL，当宕机时触发 Webhook
- 当服务器宕机时，监控系统发送一个 POST 请求到上面的 URL，请求体中包含了 "服务器192.168.1.1 已离线" 的文本信息
- Slack 接收到 Webhook 请求后，自动以 "预警助手" 的名字，把请求体中的文本信息发送到了运维人员的 Slack 频道上
- 运维小李立即收到 Slack 信息，查看服务器并处理故障
Webhook 和 API 有什么区别
假设你在一个电商网站上购买了商品， 你可以通过主动查询订单 API 来获取订单状态和物流信息。这是 API 的使用方式，通信流是单向的，信息是被动获取的。
若电商网站可以通过 Webhook 让物流公司主动推送订单状态。一旦订单发货，物流系统就主动发送一个 HTTP 请求到电商系统提供的 Webhook 回调地址，将发货和物流信息推送过去。这种主动推送就是 Webhook。
再举个简单的例子。API 是你主动问老师: "请问我的考试成绩出来了吗?" 然后老师告诉你结果。Webhook 则是老师主动在考试出分后通知你: "同学，你考了90分，成绩已经出来了。" 当然前提是你得关心你的成绩。
所以 Webhook 和 API 最大的区别是信息的流通方向，Webhook 场景中提供 URL 的是消费方，API 则是服务方，Webhook 是一种反向的 API。
Webhook 与 API 轮询，Websocket 有何不同
大家可能还知道轮询和 Websocket 这两种常用的主动获取（推送）数据的方式，那么它们和 Webhook 有何不同呢？
相比于 WebSocket：
- WebSocket 是持续的双向通信通道，需要维持连接。Webhook 是不连续的 HTTP 回调。
- WebSocket 更适合频繁的实时交互。Webhook 更适合重要事件的即时通知。
- WebSocket 有更高的使用复杂性。Webhook 基于简单的 HTTP 协议，更容易实现。
与轮询的区别：
- 轮询是客户端主动周期性请求数据。Webhook 是服务器主动推送数据。
- 轮询会产生大量无效请求和流量。Webhook 消息更精确和即时。
- 轮询有频率和时效问题。Webhook 主动推送，超低延迟。
Webhook 只会在事件发生时发送最小通知，更轻量级和即时。基于 HTTP ，也更容易跨平台集成，兼容性好。对服务器压力较小，所以 Webhook 特别适合进行事件通知。
Webhook 的安全机制
由于 Webhook 的 URL 是需要由消费方提供给服务方的，这，在这个过程可能导致 Webhook url 的泄露，比如你不小心把某个群聊飞书机器人的 Webhook url 粘贴到公开平台了，而这个 Webhook又没有配置任何安全措施导致被其他人滥用，那你的群里可就热闹了，机器人会变成你们群聊中最啰嗦的一员。
所以，除了要保管好 Webhook URL，尽量避免外泄，配置一些 Webhook 的安全机制也是很有必要的，常见的安全机制有如下三种：
- IP 白名单：服务器只接收在 Approved IP 列表 中的请求。就像一个酒店只会让认证的客人自由出入。
- 携带认证信息：在请求头或参数里加用户名/密码等身份信息。就像网吧要登记身份证才给你开机上网。
- 数据加密 ：对请求的数据加密，让别人无法读取。像手机支付的 Ast Transfer 是加密的，密码在传输过程中不会被泄露。Body 数据加密又通常使用这两种方式：
- 参数化和 HMAC：向请求中添加随机参数或时间戳参数，然后使用 HMAC 算法基于密钥计算请求数据的哈希作为签名，发送给客户端。客户端可以验证签名的正确性。
- JSON Web Tokens：使用 JWT 标准中的数据加密方法对请求 Payload 部分加密，保证数据安全性。
如何实现 Webhook
消费方要做的事情：
- 定义回调接收接口（URL）: 提前准备用于接收 Webhook 数据推送的接口地址，并对外公开。
- 接口验证: 在接口中验证请求来源的合法性，如签名、时间戳等，确保请求的安全性。
- 解析推送数据: 对请求体中的数据进行格式化和解析，以获取业务事件的相关信息。
- 触发业务流程: 根据解析后的事件内容，触发相应的业务逻辑，完成后续动作。
- 返回响应: 给服务方一个确认的响应，表示成功接收到数据。
服务方要做的事情：
- 注册事件和回调接口: 记录下消费方配置的响应回调接口 URL 和触发回调所需的业务事件。
- 检测事件触发条件: 通过代码、任务或触发器等方式，检测所注册的业务事件是否发生。
- 构建请求数据: 根据定义好的数据格式，构建要推送的请求体。
- 发送请求: 向注册的消费方接口地址发送 Webhook 请求，将事件数据推送给消费方。
- 处理响应和重试: 处理消费方的响应结果，如果请求失败，则进行重试推送。
整体流程与实现一个普通 API 类似，只是 Webhook 是从服务端到另一个服务端的请求，而且 url 是需要主动暴露的。
Webhook 标准化
目前关于 Webhook 已经有社区在推动规范化和标准化：www.standardwebhooks.com/ ，社区中定义了一套可预期和可扩展的 Webhook 规范，主要提到了 Webhooks 广泛用于向 API 用户发送事件，但生态系统过于碎片化，而碎片化阻碍了提供商和消费者的技术发展。因此在整个行业标准化 Webhooks 被提出，作为解决安全性和兼容性等问题的解决方案。
目前主流协作办公/IM 平台暴露的 Webhook 所需的响应体各不相同。飞书，企业微信，钉钉，slack，teams 几乎是一人一套规范，它们从数据格式，加密机制到事件类型都存在差异，给开发者集成增加了额外工作量。这也是为什么行业内呼吁标准化 webhook 的原因之一。
提议的标准化包括基于现有行业最佳实践的严格指南，以及有关 Payload 结构的正式规范。 关于安全性、可靠性、互操作性的标准化设计目标，以及满足现有 Webhook 实现的向后/向前兼容性。Payload 结构是每个 Webhook 的核心部分，应以 JSON 格式在 HTTP 体中传递。标准中为不同事件类型和元数据提供了Payload 结构示例。
最关键是提供了一套社区驱动的工具和指南，用于开源和社区采用标准化，主流语言都可以通过 SDK 快速实现标准化的 Webhook。
总结
这篇了 Webhook 的工作原理、安全性考量、最佳实践以及各种使用场景。Webhook 通过其 "推" 的方式实现了实时数据更新的能力。随着越来越多公司采用 Webhook，相关的安全标准和最佳实践也在不断完善。遵循这些标准有助于应用更加安全、可靠的集成外部程序。
如果文章对你有帮助请为我点个赞，respect!