图: 一个简单的流程图,左边是 Event 源 App,右边是 Event 接收 App,箭头表示通过 Webhook 请求主动讲事件推送过去
Webhooks 是用户定义的的 HTTP 回调:一种以 Event 通知的方式,由 Event 源 App 通过 HTTP POST 向 Event 接收 App 推送 Event 通知的一种方法。这种工作方式与常规 API 调用有些许不同, 和消息中间件有些许相似:
常规 API | Webhooks | 消息中间件 | |
---|---|---|---|
工作方式 | Event接收App主动向Event源App发送请求,尝试获取最新的数据 | Event源App有更新时主动推送Event给Event接收App | 两个 App 间的 Message 的传递、转换等功能 |
实时性 | 数据实时性/一致性取决于API请求频次 | 数据保持实时更新 | 数据保持实时更新 |
资源消耗 | 无论源 Event App 侧是否存在数据更新,Event 接收 App 都要进行 API 请求,浪费资源 | 只有在发生特定的事件时,才需要处理和传递Event | 只有在发生特定的事件时,才需要处理和传递Message |
Webhooks的实施并非易事,因为需要考虑多个因素:
问题 | 描述 | 解决方案 |
---|---|---|
安全性 | Fake请求攻击、重放攻击。 | 请求签名(Request Signture)、传输加密(https)、API白名单(whilelist)、timestamp验证(五分钟以外请求不处理))、幂等(重复请求不会重复处理)等。 |
失败处理 | 需要考虑服务器宕机、网络故障、Event 接收 App 发版、Endpoint 临时不可用 等因素 | 可以引入重试、重放等机制 |
投递保证 | 确保每个请求都能被正确及时地传送到预定的Endpoint | 最多一次,至少一次,只有一次三种模式。 |
测试 | 需要确认 Webhooks 在实际环境中的表现 | 手动测试和自动化测试。可以使用函数猫来模拟和测试Webhook。 |
下一讲,我们将深入研究使用Webhooks的好处:实时性、高效性、以及自动化。希望你继续跟随我们一起,揭开Webhooks带来的无尽可能性的神秘面纱。