随着软件继续吞噬世界，对实时信息、无缝集成和自动化的日益重视已将 Webhooks 推向了现代应用程序架构的最前沿。 Webhooks 现在是跨平台驱动基于实时事件的工作流程的核心组件。您可以 。 在此处阅读完整报告 特别感谢 Zoom 的 Ojus Save、Intuit 的 Judy Vander Sluis、Cloudinary 的 Sharon Yelenik、Github 的 Sarah Edwards 和 ReadMe 的 Kanad Gupta 与我们合作进行 webhook 文档审查。它确实帮助我们了解了人们如何考虑记录他们的 webbook API，并在创建此报告时为我们的许多决策提供了信息。 在这份关于 2023 年 Webhooks 状况的综合报告中，我们研究了 100 多家顶级 API 提供商，研究了他们如何接受和实施 Webhooks，并分析了这些实施的不同方式。大多数领先的 API 提供商是否都采用了最佳实践？除了单纯的采用之外，他们如何优化、保护和丰富其 Webhook 产品以满足当今开发人员和企业的需求？ 认识到现实世界的用例中经常出现基本事实，我们利用了自己的客户群，编制了一系列有趣的统计数据，揭示了 Webhook 交付的现实情况。他们在野外多久会蹒跚而行？这些消息通常需要重试多少次才能成功到达目的地应用程序？这些第一手统计数据不仅提供了当前交付成功率的清晰图景，而且还证明了实施最佳实践的价值。 一般来说，我们发现 Webhook 的采用率高达 83%。然而，大多数最佳实践的采用都是滞后的。 重试 重试涉及在尝试失败时重新发送 Webhook。它们对于可靠的 Webhook 服务至关重要，因为临时网络问题、服务器停机或其他暂时性错误可能会阻碍即时数据传输。 67% 的服务提供自动重试。最常见的重试次数是 5 次，大多数提供 3-10 次重试。大约 10% 的服务表示他们重试了失败的消息，但没有提供有关重试计划本身的任何信息。 重试：指数退避 Webhook 重试使用指数退避来有效处理故障，而不会压垮接收服务器。 通过逐步增加重试之间的等待时间，它可以降低潜在服务器问题加剧的风险，并提供更具适应性的方法来处理暂时性故障。 总之，大多数 API 提供商都在采用 Webhooks，但他们大多未能实现最佳实践。即使那些确实实施了大多数最佳实践的企业也以不同的方式实现。这个领域是如此分散，唯一具有类似实现的提供商是那些根本没有实现最佳实践的提供商。希望这份报告能够激发更多人采用 Webhook 最佳实践，以帮助改善开发人员围绕 Webhook 的体验。 手动重试 能够手动重试消息可以加快故障排除速度。立即触发重试比等待下一次自动重试更快。 12/83 提供商指定可以手动触发重试。这是最少采用的最佳实践。 记录 对于测试、故障排除和调试目的，Webhook 传递尝试的日志非常有用。这是采用率第二低的功能，采用率为 23%。 事件类型 将提供给 Webhook 使用者的事件组织为事件类型，让用户可以选择他们想要接收哪些事件的 Webhook，并减少发送的不必要和不相关的消息数量。 93% 的提供商提供活动类型。这是最广泛采用的最佳实践，可能源于事件是 Webhook 的核心价值这一事实。 消息认证 为用户提供一种方法来验证 Webhook 消息的来源和内容对于确保数据在传输过程中不被篡改并确认其来自可信来源至关重要 83 个 Webhook 提供商中有 45 个包含时间戳。时间戳对于防止重放攻击至关重要。 文档 很好地记录 Webhook 服务可以节省用户时间，让他们不再头疼。 拥有示例代码可以让开发人员的生活更轻松。虽然只有 43% 提供了代码示例，但代码示例的包含与使用 HMACSHA256 签名密切相关。 测试 最好的 Webhook 文档提供了有关如何测试其 Webhook 实现的指导。常见指南包括如何在本地测试 Webhook（主要使用 ngrok）、列出用于启动端点以接收测试消息的各种工具，以及提供发送测试事件的功能。 拥有代码示例与提供测试 Webhook 的指导和工具之间存在高度相关性。 送货 在完整报告中，我们还提供了 Svix 的一些内部数据，以了解消息失败的频率、重试成功的频率、平均响应时间以及 Webhook 消息的平均负载大小。 阅读完整报告 如需了解更多此类内容，请务必在 、 或 上关注我们，了解 的最新更新，或加入 上的讨论。 Twitter Github RSS Svix webhook 服务 我们社区 Slack
