WebHook 简介

大多数人讨厌被微观管理，我们大多希望能够尽心尽力地工作，而不是被不断地提醒，或者在明显还没完成的情况下被反复询问是否完成。这种来自直接上司和同事的行为已经迫使一些工程师向他们致敬并辞职。

但是，当你反复向你的服务器端应用程序发送请求，请求显然尚未准备好或根本不存在的数据时，它会对运行在 AWS 或 Azure 上的应用程序产生完全相同的感受，你会作何感想？
我敢肯定，我们肯定不希望服务器端应用程序在无法承受来自我们和客户端的反复调用和请求时，就此放弃它的工作。毫不奇怪，像 GitHub 这样的产品会强制限制你向其服务器发出的请求数量，只是为了安全起见，确保他们的服务器端应用程序能够正常运行，不会因为不受控制的访问而导致数十亿个请求的出现而自动退出🎩。

现在，大家心中的疑问是：如果我们不再需要反复询问服务器是否有新内容，那么我们如何才能感知到服务器的变化？还是说，我们只能期望用户每 10 分钟刷新一次浏览器才能获取新内容？

如果我们运行的产品需要读取大量数据，例如 Twitter 和 GitHub，我们绝对不会期望用户每次想要获取最新信息或动态时都刷新浏览器，至少在这个 SPA 和 Ajax 盛行的时代是这样。那么，
我们该如何解决这个问题呢？

隆重介绍大人物...WebHooks 🥁🥁🎉🎉🎊🎊

WebHooks 的引入带来了客户端应用程序和服务器端应用程序之间新的通信形式。
在此之前，客户端和服务器端之间的通信形式是客户端在向服务器发出资源请求时消耗服务器资源。

使用 WebHook，这次是服务器端使用来自客户端的资源，而不是相反（该资源是客户端应用程序提供的端点 URL），这就是为什么 WebHook 通常被称为“反向 API ”。

WebHook 的概念很简单。WebHook 是一个HTTP callback或HTTP POST，当某些事情发生时触发；一种简单的事件通知方式HTTP POST。
有了 WebHook，我们无需客户端应用程序不断轮询服务器端应用程序来查找某些资源，而是只要客户端感兴趣的资源发生变化，就会收到警报。

因此，客户端应用程序不会不断轮询服务器端应用程序来检查新事件，而是在服务器端有新内容要报告给客户端时，服务器端应用程序会调用客户端应用程序（通过调用客户端提供的 webhook URL）。

Webhook 不仅能够通知客户端服务器端的变化，还能接收有效载荷，该载荷可以是有关新资源的信息。虽然可以在 Webhook 主体内传递有效载荷数据，但为了提高可扩展性和可靠性，最好保持 Webhook 的轻量级。虽然 Webhook 从技术上来说可以承载有效载荷，但它仅仅是一种回调机制，主要作用是作为状态变化的信号。

一旦收到状态变化通知，就可以向服务器发出单独的 API 调用，请求新的资源。这种关注点分离可以提高 API 集成的可扩展性和可靠性。Twitter 和 LinkedIn 正是这样做的：它们允许你更新时间线，但只有当有新资源（推文或帖子）时才会显示更新按钮。

因此，Webhook 只不过是客户端提供的一个简单的端点 URL。客户端应用程序必须在服务器端调用 Webhook 之前的某个时间点将此端点 URL 传递给服务器端应用程序。

资源：

1. 以下网站https://webhook.site/允许您测试 webhook 的概念。它会生成一个唯一的测试 webhook URL，您的应用程序可以调用该 URL 来测试 webhook 的回调（通知）功能。您可以进一步测试，将生成的 webhook 链接添加到 GitHub 仓库的 webhook 设置中，并推送到该仓库，从 webhook.site 体验 webhook 的强大功能。

2. 关于 webhook 是否应该有有效载荷的争论，可以看看jsneddles 在 Medium上发表的这篇文章

3. 如需进一步了解，请查看https://codeburst.io/whats-a-webhook-1827b07a3ffa

结论：
由于我刚刚理解这个概念，所以有可能，我还没有接触到它的所有方面，希望能得到大家的反馈、提问和贡献。谢谢。