Vincent Le Goff
ソフトウェア・エンジニア
スタンダード Webhook の提供を開始しました！
Kong は、 Svix （プロジェクトの発起人）、 Ngrok 、 Zapier 、 Twillio 、 Lob 、 Mux 、 Supabase といった他の大手企業とともに、この標準の技術委員会に参加してきました。これは、フィードバック、ユースケースを収集し、何をどのように定義するかについて議論する1 年にわたる取り組みでした。
スタンダード Webhook は、プロデューサーとコンシューマ が、通信するための契約を結ぶ方法を標準化するためのイニシアチブの1つです。これは、これらの契約を安全で統合しやすくするためのガイドラインとライブラリのセットを含むオープンソースのリポジトリによって実現されます。
詳細は GitHub リポジトリと公式ウェブサイトをご覧ください。
Webhookとは？
Webhook は HTTP コールバックとして機能し、サービス間でイベントの通知を可能にします。Webhook は 「 リバース API 」として機能し、クライアントが API コールを介してサービスへのリクエストを開始する代わりに、サービスがプロアクティブに Webhook をトリガーしてクライアントにアップデートをプッシュします。例えば、あるサービスが 「ユーザーが支払いを完了した 」とか 「タスクが完了した 」といったイベントに対して Webhook をトリガーする場合があります。
Webhook はサーバー間の通信を容易にします。クライアント/顧客および関与するサービスプロバイダーは通常、独自の HTTP サーバーを運用します。1つのサーバーは API コールを受信し、もう1つのサーバーは着信 Webhook を受信します。Webhook はしばしば従来の API を補完しますが、これは必須条件ではありません。一部のサービスは、クライアントが更新をポーリングするための API を提供するのではなく、プッシュ通知のための Webhook だけに依存しています。
Webhook はますます人気が高まっており、世界のトップ企業の多くが API のユーザーにイベントを送信するために使用しています。しかし、エコシステムは断片化されており、各 Webhook プロバイダーは異なる実装を使用しており、品質も様々です。高品質の実装でもばらつきがあるため、本質的に互換性がありません。
コンシューマーにとっては、プロバイダーごとに Webhook の扱い方が異なり、Webhook の検証方法を学び直し、オーダーメイドの実装で問題が発生することを意味します。プロバイダーにとっては、車輪の再発明や、すでに解決された問題（セキュリティ、互換性など）の再設計を意味します。このような断片化は、プロバイダーと消費者にとって苦痛であり、イノベーションを阻害します。
提案はシンプルで、業界全体で Webhook を標準化することです。私たちは、既存のベストプラクティスに基づき、一連の厳格な Webhook ガイドラインを成文化しました。
もう1 つの指針は、未使用の完璧な仕様よりも、広く採用されている優れた仕様の方が良いということでした。この北極星によって、チームは優れた開発者エクスペリエンス・ツールセットを構築しています。
なぜこのプロジェクトを支援するのか？
Kong Konnect ユーザーであれば、Webhook を使った監査ログ機能をすでにご存知かもしれません。これは Konnect の最初の Webhook 機能であり、エンジニアリングは2024年に向けてさらなる機能の開発に取り組んでいます。
このエコシステムには標準が存在しないため、X、Y、Z をどのように公開するかでチームが同調する必要があり、消費者の視点からは実装が異質なものになります。これは、開発の遅れと開発者と消費者の潜在的な摩擦につながる可能性があります。
技術的な観点から言えば、Kong Connect はすでにいくつかのベンダーの Wenhook を利用しており、「 Webhook の検証方法を再学習したり、特定の実装における落とし穴に遭遇したりする」という問題は、私たちの開発から抽象化したいと考えています。
OIDC による認証と認可、mTLS によるゼロトラスト、OpenAPI による API 定義など、他の多くの分野はすでに解決されています。今度は Webhook の時代です。
次はどうする？
Kong はこのプロジェクトの中心的な貢献者であるため、Kong Konnect 、Kong Gateway 、または Kuma のいずれかの製品を通じてこの標準を推進するよう努めていきます。
