Webhook とは何ですか?どのように使用しますか?

Webhook を使用すると、Web ベースのアプリケーションがカスタム コールバックを使用して対話できるようになります。

Webhook を使用すると、Web アプリケーションが他の Web アプリケーションと自動的に通信できるようになります。

あるシステム (サブジェクト) が別のシステム (オブザーバー) にデータをポーリングし続ける従来のシステムとは異なり、Webhook を使用すると、イベントが発生するたびにオブザーバーが自動的にデータをサブジェクトのシステムにプッシュできます。

これにより、被験者による常時監視の必要がなくなります。 Webhook は完全にインターネット上で動作するため、システム間のすべての通信は HTTP メッセージの形式で行われる必要があります。

Webhook の使用

Webhook は、オブザーバーのシステムでイベントが発生したときに通知する必要があるサブジェクトのシステム内の API を指す静的 URL の存在に依存します。 この例としては、ユーザーの Amazon アカウントで行われたすべての注文を収集および管理するように設計された Web アプリが挙げられます。 このシナリオでは、Amazon がオブザーバーとして機能し、Custom Order Management Webapp がサブジェクトとして機能します。

カスタム Web アプリで Amazon API を定期的に呼び出して、作成された注文を確認する代わりに、カスタム Web アプリで作成された Webhook を使用すると、Amazon は登録された URL を介して Web アプリで新しく作成された注文を自動的に送信できます。 したがって、Webhook の使用を有効にするには、サブジェクトはオブザーバーからのイベント通知を受け入れる URL を指定する必要があります。 これにより、イベントが発生した場合にのみ HTTP 呼び出しが XNUMX 者間で行われるため、オブジェクトの負荷が大幅に軽減されます。

ポーリングベースのシステムと Webhook ベースのシステムの比較

サブジェクトの Webhook がオブザーバーによって呼び出されると、サブジェクトはこの新しく送信されたデータに対して適切なアクションを実行できます。 通常、Webhook は特定の URL への POST リクエストを介して実行されます。 POST リクエストを使用すると、オブジェクトに追加情報を送信できます。 さらに、イベントごとに個別の Webhook URL を作成する代わりに、考えられるさまざまなイベントを識別するために使用することもできます。

Webhook ワークフロー

アプリケーションに受信 Webhook を実装するには、次の基本手順を実行する必要があります。

• HTTP POST 呼び出しを受け入れて処理する API エンドポイントをアプリケーション サーバー上に公開します。
• 潜在的な Webhook ユーザーにこのエンドポイントへのアクセスを提供します。 API エンドポイントは、関連する条件が満たされるたびにデータ ソース アプリケーションを呼び出します。
• POST データを処理し、Webhook 呼び出しイニシエーターにステータスを示す応答を返します。 このステップは存在する場合と存在しない場合があります。

Webhook と API

Webhook と API はどちらも、アプリケーション間の通信を確立することを目的としています。 ただし、アプリケーションの統合を実現するために API ではなく Webhook を使用することには、明確な利点と欠点がいくつかあります。

次の点が実装されたシステムに関連している場合、Webhook はより良いソリューションとなる傾向があります。

• サーバー上でデータが頻繁に更新される場合は、クライアントからサーバーへの不要な API 呼び出しが排除されるため、Webhook の方が優れたソリューションとなる傾向があります。 resthooks.com によると、API 調査の 98,5% が無駄になります。
• Webhook により、ほぼリアルタイムのデータ更新を必要とするシステムにとって、より優れたソリューションが可能になります。 API ポーリングは通常、設定された間隔で実行されるため、ライブ データが更新されない場合があります。 Webhook を使用すると、Webhook がトリガーされるとすぐに更新がサーバーからクライアントに送信されます。

他の状況では、Webhook よりも API の使用を優先する必要があります。

考慮事項

Webhook で API を使用する場合に考慮すべき重要な点は次のとおりです。

• API を使用すると、サーバーからデータをいつポーリングするか、またサーバーからポーリングするデータの量をさらにカスタマイズできます。 ポーリングされるデータの量は、API ポーリング サイズによって決まります。 Webhook では、通常、サーバーがデータとその送信時期を決定します。
• 非常に変動性の高いデータを含むシステム (リアルタイム システム、IoT システムなど) の場合は、API 呼び出しごとに使用可能な応答が得られる可能性が高いため、API ベースのポーリングの方が良い選択肢になる可能性があります。
• REST エンドポイントがオフラインの場合、Webhook を介してサーバーから送信されたデータがクライアントによって完全に無視される可能性があります。 サーバーにそのような失敗したプッシュを再試行するメカニズムがない場合、データの更新は完全に失われます。

Webhook がオフラインになったときにサーバーから送信されたデータが失われる可能性に対処するために、イベント メッセージング キューを使用してそれらの呼び出しをアーカイブできます。 このような機能を提供するプラットフォームの例には、次のものがあります。 RabbitMQの o Amazon のシンプル キュー サービス (SQS)。 どちらも、Webhook 呼び出しを見逃す可能性を回避する中間メッセージング ストレージ機能として機能するように設計されています。

Ercole Palmeri