Webhook 在现代应用程序网络中几乎无处不在。每当你收到由事件触发的自动消息时,都可能使用了 webhook。
从聊天消息到电子邮件注册、付款确认等,webhooks 部署在无数应用程序中。事实上,Twitter、Discord、Slack、Github 和 YouTube 都依赖 webhooks 来运行。由于 webhook 在当今的实时软件架构中无处不在,因此了解它们的工作原理至关重要。
Webhook 介绍
Webhook 的名字就能看出,它就是一个网络钩子,或者说是一个 API 概念,正在变得越来越流行。当我们能用事件描述的事物越多时,Webhook 就越有用。许多 Web 应用程序利用 Webhook 相互通信。无论是通过 IFTTT 或 Zapier 同步应用程序,还是使用 Jenkins 自动化软件部署,webhook 都是从服务器检索实时更新的便捷方式,允许客户端在状态立即发生变化时接收通知。然后,客户端可以使用此数据来启动其他服务器进程或面向用户的操作。
从功能上讲,Webhook 基本上是通过 HTTP URL 提供的用户定义的回调。应用程序订阅服务器事件,一旦发生更新,服务器就会以负载响应,通常以 JSON 或 XML 内容类型发送。平台通常提供 Web UI 来生成 Webhook 集成和选择事件订阅。有些甚至提供基于 API 的 webhook 管理(我们稍后会讨论)。
配置 webhook 后,您将其定向到一个 URL,该 URL 充当监听站。例如,URI 路径可以构造为 https://mydomain.com/service/listen. 或者,接收 webhook POST 负载的本地 URL 可能看起来像 http://localhost:4567/payload.
Webhook 相当于是一种用于实时通知的机制,可以在特定事件发生时向一个特定的 URL 发送数据,更准确的说,它是一种 Web 回调,或者 http 服务的一个 push API。它的工作原理是,当一个特定事件发生时,应用程序会发送一个 HTTP 请求到 Webhook 的 URL,这个 HTTP 请求包含了相关的数据。然后,Webhook 接收到这个请求后,就会执行一些特定的操作,比如将这些数据存储到数据库中,或者将这些数据发送到另一个应用程序中。这里使用一个 hexo 部署的例子来说明。当我们在 GitHub 上更新了博客的内容时,GitHub 就会向我们的服务器发送一个 HTTP 请求,然后我们的服务器就会接收到这个请求,然后执行一些特定的操作,比如将这些数据存储到数据库中,或者将这些数据发送到另一个应用程序中。而如果不使用 webhook,那么我们就需要不断地轮询 GitHub,来检查是否有新的内容,这样会导致服务器的负载和网络流量增加。
与 Webhook 类似的技术还有轮询和长轮询。轮询是一种周期性地向服务器发送请求以获取最新数据的方法。而长轮询则是一种保持连接的方法,当服务器有新数据时,会立即将数据推送给客户端。
相比之下,Webhook 更加高效和实时,因为它不需要不断地发送请求来检查是否有新数据。它只会在特定事件发生时才会发送数据,这样可以减少服务器的负载和网络流量。此外,Webhook 还可以保证数据的准确性,因为它只会在特定事件发生时才会发送数据,而不是周期性地获取数据。
Webhook 与 REST API
Webhook 和 API 有何不同呢?Webhook 类似于 API,但它们是独一无二的。虽然两者通常都使用 HTTP 作为传输协议,但 REST API 采用同步请求-发送通信模型,而 webhooks 使用异步发布-推送模型。与使用 API 进行轮询(您定期调用服务器)不同,webhook 方法的资源效率更高。Webhook 的实时性也可以对用户参与度产生积极影响。
Webhook 的使用场景
Webhook 的使用场景非常多,比如:
- 💬聊天:常用于聊天应用程序,比如 Slack、Discord、Telegram 等。例如每当有新用户进群,就会发送一条消息;
- 📢通知:常用于通知应用程序,比如 GitHub、GitLab、Jenkins 等。例如每当有新的提交时,就会发送一条消息;
- 📧邮件:常用于邮件应用程序,比如 SendGrid、Mailgun、Mailchimp 等。例如确认电子邮件订阅,自动发送后续电子邮件。
- 📝日志:常用于日志应用程序,比如 Loggly、Logstash、Logentries 等。例如每当有新的日志时,就会发送一条消息;
- 📊监控:常用于监控应用程序,比如 Datadog、New Relic、Sentry 等。例如每当有新的错误时,就会发送一条消息;
- 👨💻基于事件的工作流程:常用于工作流程应用程序,比如 Zapier、IFTTT、Microsoft Flow 等。例如每当有新的事件时,就会执行一些操作;
- ☁️云存储:常用于云存储应用程序,比如 Amazon S3、Google Cloud Storage、Azure Blob Storage 等。例如用于将本地文件更改与远程服务器同步,减少手动工作量。
要了解 webhook 的强大功能,我们可以看一个简单的例子。我们都使用过京东或者其他购物平台,他们上面的商品价格是经常变动的,如果我们想要购买某个商品,但是价格太高了,而这时候有个功能叫做“降价通知”,当商品价格降到我们想要的价格时,就会通知我们,这样我们就可以购买了。这个功能就是通过 webhook 实现的。
Webhook 的优点
Webhook 的优点包括:
- 高效:减少服务器的负载和网络流量。
- 实时:可以实现实时通知和数据传输。
- 准确:可以保证数据的准确性。
Webhook 的实现及常见的 Webhook
Webhook 的实现方式有很多种,比如常用的一些流程是,将 Webhook 的请求发送到一个 URL,然后在这个 URL 上监听请求,并进行处理。这个 URL 可以是一个 Web 服务,也可以是一个 Web 应用。
- Webhook 服务。比如 GitHub 的 Webhook 服务。
- Webhook 应用。比如 Linux 的 Webhook 应用。
- Webhook 库。比如可以使用 Python、JavaScript 等语言来实现 Webhook。
Github Webhook
GitHub 平台上有很多事件,很多都可以用 webhook 来监控。使用 GitHub webhook,您的应用程序可以在有人创建分支、推送代码、分叉存储库或收藏存储库或其他操作时进行订阅。GitHub 还提供了三个 API 来创建、更新、删除和测试 webhooks:Repository Webhooks REST API、Organization Webhooks REST API 和 GitHub App Webhooks REST API。通过与 GitHub webhooks 集成,组织可以将 GitHub 更新集成到聊天环境中,以帮助所有开发人员及时了解新变化。
Slack Webhook
同样,流行的团队协作软件 Slack 提供 webhooks 来集成功能。Slack 提供传入的 webhooks 用于在触发事件时将消息发布到 Slack 频道,例如当有人提到您的名字时。他们也有传出的 webhooks 来启用对话响应。应该注意的是,在撰写本文时,Slack webhook 被视为遗留功能。相反,建议使用 Slack Apps构建自定义集成并发布到 Slack 市场。
Discord Webhook
Discord 提供了创建与其核心协作平台相关的 Webhook 的能力,允许发布自动消息。Discord 用户可以使用Discord 的 web UI 通过几个步骤创建一个新的 webhook URL 。此 URL 接收来自外部应用程序的操作。例如,Discord 上的开发团队可以将 GitHub 提交或分析从 DataDog 发送到这个 webhook,它会自动通知聊天组。Discord 提供了一个 API 来通过 HTTP POST 请求创建和修改 Discord webhook。
Webhook 的调试
如何测试网络钩子?正如我们在上面看到的,一些平台提供了 webhook 测试环境。但是,也有第三方工具,如Webhook.site和RequestBin,可以帮助测试 webhook(以及任何其他传入的 HTTP 请求或电子邮件)。由于 webhook ping HTTP URL 以执行任务,因此测试 webhook 与测试 API 端点非常相似。因此,您也可以使用 Postman 或其他 API 测试应用程序来测试 webhook。
要测试 webhook,您需要一个将接受通知的 webhook URL。要测试 webhook 是否正常工作,请使用所有必需参数向 URL 发出 POST 请求。以这个 webhook URL 为例:http://my-webhook-example/send-nofitications. 它需要两个参数,即令牌和信息,如果成功,它应该返回{“状态”:200,“结果”:“消息已发送”}. 所以,一个请求应该是这样的:
POST: http://my-webhook-example/send-nofitications |
请求正文
{ |
如果 POST 请求成功,它可能会返回 2xx HTTP 状态代码,这意味着 webhook 已正确执行。4xx 或 5xx HTTP 状态代码将指示客户端或服务器错误。
另外,我们还可以下述流程来测试 webhook:
- 明白 Webhook 的工作原理和提供的功能,这样就可以知道如何触发事件,从而使用 RequestBin 之类的工具来收集 Webhook 的请求;
- 使用 Postman 或者 curl 来模拟 Webhook 的请求;
- 使用 ngrok 来帮助将其实现内网穿透,完成测试;
- 使用 Runscope 来查看整个流程;
基于 API 的 webhook 管理
有很多方法可以测试 webhook。同样,有很多方法可以配置实际的 webhook 订阅。平台通常提供一个 UI 来创建 webhook、订阅新事件、编辑响应 URL 和删除 webhook。然而,一些平台更进一步,提供了一个 API 来以编程方式管理 webhooks。
例如,Hubspot 提供了一个 Webhooks API 以编程方式配置 webhook 设置。例如,如果我们想增加你的 Hubspot webhook 可以处理的最大并发请求,你可以做一个得到向 Hubspot Webhook API 请求调整您的应用程序设置。以下是 Hubspot 文档中的示例:
GET https://api.hubapi.com/webhooks/v1/{appId}/settings |
请求正文
{ |
以这种方式处理 webhook 订阅提供了比使用 UI 更简化的方法。尽管编程式 webhook 管理并非在所有 webhook 提供程序中都普遍存在,但一些开发人员可能更喜欢它,尤其是那些喜欢从自己的 CLI 环境进行外部调用的程序员。
使用 OpenAPI 和 AsyncAPI 的 Webhook
围绕异步操作的趋势不断增长,流行的 API 标准(如 OpenAPI 和 AsyncAPI)开始承认这一点。
OpenAPI,以前称为 Swagger,是 API 提供商用来定义和记录其 API 的规范。OpenAPI 支持回调已有一段时间了,但从OpenAPI v3.1开始,它现在支持带有“一个新的顶级元素来描述带外注册和管理的 webhook 的 webhook”。
AsyncAPI 是 OpenAPI 的异步等价物,专门设计用于定义事件驱动的协议,如 AMQP、MQTT、Kafka、STOMP 和 WebSocket。
Webhook 的安全
首先要记住的是,由于 Webhook 会将数据发送到一个 URL,而这个 URL 是公开的,所以攻击者可以通过这个 URL 来攻击我们的服务器、发送一些错误数据等,所以我们需要对 Webhook 进行一些安全措施。
- 使用 HTTPS。来保证数据的安全性,这样就可以防止数据被窃听、篡改和伪造。
- 使用签名。来保证数据的完整性。
- 增加其他认证措施。比如使用 API Key 来认证请求。
当作为webhook的消费者时有两个重要的注意事项:
1、webhook 通过请求发送数据到你的应用后,如果你的应用存在问题,数据会丢失。确保你的应用正确性,并设置一些重试机制和错误处理机制。
2、webhook 会发出大量的请求,这样可能会造成你的应用阻塞。确保你的应用可以处理这些请求。
最后的一点建议
Webhook 是许多实时、事件驱动的应用程序的关键功能。Webhooks 包含由事件触发的小代码片段,有助于自动发送更新、消息和通知,或自动在后台推送数据。与轮询相反,webhooks 更有效,减少了不必要的 ping 并消耗更少的资源。这也是一个对开发人员友好的选项。根据 Zapier 进行的一项调查,“82% 的人表示他们更喜欢网络钩子而不是轮询。” 轮询需要开发人员维护状态和单独的基础设施,而 webhooks 很容易实现。