次の方法で共有

ASP.NET WebHooks の概要

Warnung

ASP.NET WebHook は非推奨となり、更新プログラムやセキュリティ修正プログラムを受け取らなくなります。

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

WebHook はシンプルであるため、Dropbox、GitHub Bitbucket, MailChimp, PayPal, Slack, Stripe、Trello など。 たとえば、WebHook は、ファイルが Dropbox で変更されたことを示すことができます。 または、コードの変更がGitHubでコミットされたか、PayPal で支払いが開始されたか、Trello でカードが作成されています。 可能性は無限です!

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

  • 受信側では、任意の数の WebHook プロバイダーから WebHook を受信および処理するための一般的なモデルが提供されます。 最初からDropbox、GitHub、Bitbucket、MailChimp、PayPal、Pusher、Salesforce、Slack、Stripe、Trello、WordPress、およびZendeskをサポートして出荷されますが、さらに多くのサポートを簡単に追加できます。

  • 送信側では、サブスクリプションの管理と格納、および適切なサブスクライバー セットへのイベント通知の送信のサポートが提供されます。 これにより、サブスクライバーがサブスクライブできるイベントの独自のセットを定義し、状況が発生したときに通知することができます。

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

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

WebHooks の概要

WebHook はパターンであり、サービスごとに使用方法が異なりますが、基本的な考え方は同じです。 WebHook は、ユーザーが他の場所で発生するイベントをサブスクライブできる単純な 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 処理パイプライン

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

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

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

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

  • Last updated on