ASP.NET WebHooks の概要

  • [アーティクル]

WebHooks は、Web API と SaaS サービスを結び付ける単純な pub/sub モデルを提供する軽量の 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 のみを公開する場合は、それを行うことができます。

このコードは、MVC 5 ASP.NET Web API 2 と ASP.NET ターゲットであり、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 ヘッダー フィールドや、HTTP POST 要求本文に含まれるプロパティを指定できます。

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

WebHooks 処理パイプライン

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

ASP.NET WebHooks 処理パイプライン

ここでの 2 つの主要な概念は 、Receivers と Handlers です。

  • 受信者 は、特定の送信者からの WebHook の特定のフレーバーを処理し、WebHook 要求が意図した送信者からのものであることを確認するためのセキュリティ チェックを実施する責任があります。

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

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