ソフトウェアが世界を蝕み続ける中、リアルタイム情報、シームレスな統合、自動化がますます重視されるようになり、Webhook が最新のアプリケーション アーキテクチャの最前線に押し上げられています。 Webhook は現在、プラットフォーム全体でリアルタイムのイベントベースのワークフローを推進するための中心的なコンポーネントです。 ことができます。 レポート全文はここで読む Webhook ドキュメントのレビューにご協力いただいた Zoom の Ojus Save、Intuit の Judy Vander Sluis、Cloudinary の Sharon Yelenik、Github の Sarah Edwards、ReadMe のKanad Gupta に心より感謝いたします。これは、Webook API の文書化について人々がどのように考えているかを理解するのに非常に役立ち、このレポートを作成する際の多くの決定に役立ちました。 2023 年の Webhook の状況に関するこの包括的なレポートでは、100 社を超えるトップ API プロバイダーを調査し、彼らが Webhook をどのように受け入れ、実装しているかを調査し、これらの実装がどのように形になったかを分析しました。主要な API プロバイダーのほとんどはベスト プラクティスを実践していますか?単なる採用を超えて、今日の開発者や企業のニーズに応えるために、Webhook サービスをどのように最適化し、保護し、充実させてきたのでしょうか? 現実世界のユースケースではグラウンドトゥルースがしばしば現れることを認識し、私たちは独自の顧客ベースを活用し、Webhook 配信の現実を明らかにする興味深い統計のキャッシュを編集しました。彼らは野生下でどのくらいの頻度でよろめきますか?これらのメッセージは通常、目的のアプリケーションに正常に到達するまでに何回再試行する必要がありますか?これらの直接の統計は、現在の配信成功率を明確に示すだけでなく、ベスト プラクティスを実装することの価値も示しています。 一般に、Webhook の採用率は 83% と高いことがわかりました。しかし、ほとんどのベストプラクティスの導入は遅れています。 再試行 再試行には、試行が失敗した場合の Webhook の再送信が含まれます。一時的なネットワークの問題、サーバーのダウンタイム、またはその他の一時的なエラーによって即時のデータ配信が妨げられる可能性があるため、これらは信頼性の高い Webhook サービスにとって非常に重要です。 サービスの 67% が自動再試行を提供していました。提供される再試行の最も一般的な回数は 5 回で、ほとんどの場合は 3 ～ 10 回の再試行が提供されます。約 10% のサービスは、失敗したメッセージを再試行したと述べていますが、再試行スケジュール自体に関する情報は提供していませんでした。 再試行: 指数バックオフ Webhook の再試行では、指数関数的バックオフを使用して、受信サーバーに負荷をかけることなく効率的に障害を処理します。 再試行間の待機時間を徐々に長くすることで、潜在的なサーバーの問題が悪化するリスクが軽減され、一時的な障害を処理するためのより適応的なアプローチが提供されます。 結論として、Webhook はほとんどの API プロバイダーで採用されていますが、ほとんどのプロバイダーはベスト プラクティスの実装に失敗しています。ほとんどのベスト プラクティスを実際に実装している企業でも、その方法は異なります。この領域は非常に断片化されており、同様の実装を行っている唯一のプロバイダーは、ベスト プラクティスをまったく実装していないプロバイダーでした。このレポートが Webhook のベスト プラクティスの導入を促進し、Webhook に関する開発者のエクスペリエンスを向上させることを願っています。 手動再試行 メッセージを手動で再試行できるため、トラブルシューティングが迅速化されます。次の自動再試行を待つよりも、すぐに再試行をトリガーする方が高速です。 12/83 プロバイダーは、再試行を手動でトリガーできることを指定しました。これは最も採用されていないベスト プラクティスでした。 ロギング テスト、トラブルシューティング、およびデバッグの目的では、Webhook 配信試行のログは非常に役立ちます。これは 23% の採用率で、2 番目に採用されていない機能でした。 イベントの種類 Webhook コンシューマーに提供されるイベントをイベント タイプに整理することで、ユーザーは Webhook を受信するイベントを選択できるようになり、送信される不要で無関係なメッセージの数を削減できます。 プロバイダーの 93% がイベント タイプを提供しました。これは最も広く採用されているベスト プラクティスであり、おそらくイベントが Webhook の核となる価値であるという事実に由来しています。 メッセージ認証 Webhook メッセージの送信元と内容を認証する方法をユーザーに提供することは、データが転送中に改ざんされていないことを確認し、信頼できるソースからのものであることを確認するために不可欠です。 Webhook プロバイダー 83 件中 45 件にタイムスタンプが含まれていました。タイムスタンプはリプレイ攻撃を防ぐために重要です。 ドキュメンテーション Webhook サービスを適切に文書化すると、ユーザーの時間を節約し、頭痛の種を避けることができます。 サンプルコードがあると、開発者の作業が楽になります。コード サンプルを提供したのは 43% のみでしたが、コード サンプルの組み込みは HMACSHA256 署名の使用と大きく相関していました。 テスト Webhook の最良のドキュメントには、Webhook の実装をテストする方法に関するガイダンスが記載されています。共通のガイダンスには、Webhook をローカルでテストする方法 (主に ngrok を使用)、エンドポイントをスピンアップしてテスト メッセージを受信するためのさまざまなツールのリスト、テスト イベントを送信する機能の提供などが含まれます。 コードサンプルを用意することと、Webhook をテストするためのガイダンスやツールを提供することには高い相関関係があります。 配達 完全なレポートでは、メッセージが失敗する頻度、再試行が成功する頻度、平均応答時間、Webhook メッセージの平均ペイロード サイズを確認するための Svix からの内部データも示しています。 レポート全文を読む このようなコンテンツをさらに知りたい場合は、 、 、または でフォローして の最新アップデートを入手するか、 でのディスカッションに参加してください。 Twitter Github RSS Svix Webhook サービス コミュニティ Slack
