次の方法で共有

ASP.NET WebHooks の概要

  • [アーティクル]

WebHooks は、Web API と SaaS サービスを接続するための簡単なパブリッシュ/サブスクライブ モデルを提供する軽量な HTTP パターンです。 サービスでイベントが発生すると、HTTP POST 要求の形式で登録済みサブスクライバーに通知が送信されます。 POST 要求には、イベントに関する情報が格納されており、受信側がそれに応じて行動できるようにします。

WebHooks は、そのシンプルさゆえに、Dropbox、GitHub、Bitbucket、MailChimp、PayPal、Slack、Stripe、Trello など、既に多くのサービスで公開されています。 たとえば、WebHook は、Dropbox でファイルが変更されたこと、GitHub でコードの変更がコミットされたこと、PayPal で支払いが開始されたこと、Trello でカードが作成されたことを示すことができます。 可能性は無限です。

Microsoft ASP.NET WebHooks を使用すると、ASP.NET アプリケーションの一部として WebHook を簡単に送受信できます。

  • 受信側には、任意の数の WebHook プロバイダーから WebHooks を受信および処理するための一般的なモデルが用意されています。 Dropbox、GitHub、Bitbucket、MailChimp、PayPal、Pusher、Salesforce、Slack、Stripe、Trello、WordPress、Zendesk のサポートをすぐに利用できますが、それ以上のサポートも簡単に追加できます。

  • 送信側には、サブスクリプションの管理と格納、およびイベント通知を適切な一連のサブスクライバーに送信するためのサポートが用意されています。 これにより、サブスクライバーがサブスクライブできる一連の独自イベントを定義し、何らかのイベントが発生したときに通知するようにできます。

2 つの部分は、シナリオに応じて一緒に使用することも、別に使用することもできます。 他のサービスから WebHooks のみを受信する必要がある場合は、受信側の部分のみを使用できます。他のユーザーが使用できるように WebHooks のみを公開する場合は、それのみを行うことができます。

このコードは、Web API 2 と ASP.NET MVC 5 ASP.NET を対象としており、GitHub 上の OSS として使用できます。

WebHooks の概要

WebHooks はパターンであるため、サービスごとに使用方法が異なりますが、基本的な考え方は同じです。 WebHooks は、ユーザーが他の場所で発生したイベントをサブスクライブできるシンプルな pub/sub モデルと考えることができます。 イベント通知は、イベント自体に関する情報を含む HTTP POST 要求として伝達されます。

通常、HTTP POST 要求には、WebHook をトリガーするイベントに関する情報を含む、WebHook 送信者によって決定された JSON オブジェクトまたは HTML フォーム データが含まれます。 たとえば、GitHub からの WebHook POST 要求本文は、特定のリポジトリで新しい問題が明らかになった結果、次のようになります。

{
  "action": "opened",
  "issue": {
      "url": "https://api.github.com/repos/octocat/Hello-World/issues/1347",
      "number": 1347,
      ...
  },
  "repository": {
      "id": 1296269,
      "full_name": "octocat/Hello-World",
      "owner": {
          "login": "octocat",
          "id": 1
          ...
      },
      ...
  },
  "sender": {
      "login": "octocat",
      "id": 1,
      ...
  }
}

WebHook が意図した送信者からのものであることを確認するために、POST 要求は何らかの方法でセキュリティで保護され、受信側によって検証されます。 たとえば、GitHub WebHooks には、要求本文のハッシュを含む X-Hub-Signature HTTP ヘッダーが含まれています。これは受信側の実装によってチェックされるため、心配する必要はありません。

WebHook フローは一般に次のようになります。

  • WebHook 送信者は、クライアントがサブスクライブできるイベントを公開します。 イベントは、新しいデータ項目が挿入された場合、プロセスが完了した場合など、システムに対する監視可能な変更を記述します。

  • WebHook レシーバーは、次の 4 つで構成される WebHook を登録することによってサブスクライブします。

    1. イベント通知を HTTP POST 要求の形式で投稿する必要がある場所の URI。

    2. WebHook を起動する必要がある特定のイベントを記述するフィルターのセット。

    3. HTTP POST 要求に署名するために使用される秘密キー。

    4. HTTP POST 要求に含まれる追加データ。 これは、HTTP POST 要求本文に含まれる追加の HTTP ヘッダー フィールドやプロパティなどにすることができます。

  • イベントが発生すると、一致する WebHook 登録が見つかり、HTTP POST 要求が送信されます。 通常、HTTP POST 要求の生成は、何らかの理由で受信者が応答しない場合や、HTTP POST 要求でエラー応答が発生した場合に、複数回再試行されます。

WebHooks 処理パイプライン

受信 WebHook の Microsoft ASP.NET WebHooks 処理パイプラインは次のようになります。

ASP.NET WebHooks Processing Pipeline

ここでの 2 つの重要な概念は、受信者とハンドラーです。

  • 受信者は、特定の送信者からの WebHook の特定のフレーバーを処理し、セキュリティ チェックを適用して、WebHook 要求が意図した送信者からのものであることを確認する役割を担います。

  • ハンドラーは通常、ユーザー コードが特定の WebHook の処理を実行する場所です。

次のノードでは、これらの概念について詳しく説明します。