Webhook实现疑问：替代轮询方案的技术咨询

背景场景 #

我的服务器有一个客户端，它会非常频繁地调用GET API（比如每5秒一次）获取特定事项的更新，哪怕没有新内容，服务器也要处理大量无效请求。我打算换成Webhook方案，有更新时主动调用客户端的POST API，减轻服务器负载。

我对Webhook的现有理解 #

• Webhook类似反向API，把更新内容POST到原先是轮询我方的客户端服务器上。
• 客户端需要实现一个POST API作为Webhook接收端，我方在有事件/更新时调用这个API。
• 每次有新事件，我会用REST模板调用他们的POST API。

疑问解答 #

1. 有没有Webhook服务器？有的话怎么创建实现？ #

当然有，但其实Webhook服务器就是你的服务端——它的核心职责是在业务事件触发时，主动向客户端提供的Webhook URL发起请求。

实现核心步骤：

• 存储客户端Webhook配置：包括他们提供的接收URL、双方约定的签名密钥、订阅的事件类型等，可存在数据库或配置中心。
• 监听业务事件：比如当特定事项发生更新时，触发Webhook发送逻辑。
• 组装请求并发送：把更新数据打包成请求体，用HTTP客户端（比如你提到的REST模板）发送POST请求到客户端的Webhook URL。
• 处理重试机制：如果请求失败（网络波动、客户端服务不可用），将请求加入重试队列，采用指数退避策略（如首次等待10秒，二次20秒，以此类推）避免频繁重试。

2. Webhook只是反向API吗？有没有需要双方配合的特殊事项？ #

Webhook本质是触发式的反向API，但远不止简单的反向请求，双方有不少必须配合处理的细节：

• 签名验证：你发送请求时，用约定密钥对请求体生成HMAC签名并放到请求头；客户端收到请求后，用同一密钥验证签名，确保请求来自你的服务，防止伪造。
• 事件订阅管理：客户端应能自主选择订阅的事件类型，而非接收所有更新；你需要提供注册、修改、删除Webhook的接口，供客户端管理订阅。
• 幂等性保障：网络波动可能导致重复发送同一事件，客户端需能识别重复请求（比如你在请求中加入唯一事件ID），避免重复处理造成数据混乱。
• 响应规范：客户端收到请求后需快速返回2xx状态码表示已接收；若处理耗时，需异步处理，避免请求超时触发你的服务重试。
• 错误告警：若多次发送请求失败，你需通知客户端（如邮件、专属告警接口），提醒排查Webhook接收服务的问题。

内容的提问来源于stack exchange，提问作者Yashpal