Omówienie ASP.NET WebHooks

WebHooki to lekki wzorzec HTTP, który zapewnia prosty model publikacja/subskrypcja do łączenia webowych API i usług SaaS. W przypadku wystąpienia zdarzenia w usłudze powiadomienie jest wysyłane w postaci żądania HTTP POST do zarejestrowanych subskrybentów. Żądanie POST zawiera informacje o zdarzeniu, które umożliwia odbiornikowi odpowiednie działanie.

Ze względu na ich prostotę, WebHooki są już udostępniane przez wiele usług, w tym Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello i wiele innych. Na przykład element WebHook może wskazywać, że plik został zmieniony w Dropbox, lub w GitHub została zatwierdzona zmiana kodu lub zainicjowano płatność w PayPal lub karta została utworzona w Trello. Możliwości są nieograniczone!

Microsoft ASP.NET WebHooks ułatwia wysyłanie i odbieranie WebHooks w ramach aplikacji ASP.NET.

• Po stronie odbiorczej zapewnia wspólny model odbierania i przetwarzania WebHooków od dowolnej liczby dostawców WebHooków. Dostępne od razu z obsługą Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello,WordPress i Zendesk, ale łatwo można dodać obsługę więcej usług.

• Po stronie wysyłania zapewnia obsługę zarządzania subskrypcjami i ich przechowywania, a także wysyłania powiadomień o zdarzeniach do odpowiedniego zestawu subskrybentów. Dzięki temu można zdefiniować własny zestaw zdarzeń, do których subskrybenci mogą subskrybować i powiadamiać ich, gdy coś się stanie.

Dwie części mogą być używane razem lub od siebie w zależności od scenariusza. Jeśli potrzebujesz tylko otrzymywać WebHooki z innych usług, możesz użyć tylko części odbiorczej; Jeśli chcesz tylko udostępnić WebHooki dla innych użytkowników do użycia, możesz to zrobić.

Kod jest przeznaczony dla ASP.NET Web API 2 i ASP.NET MVC 5 i jest dostępny jako OSS w GitHub.

Omówienie WebHooków

WebHooks to wzorzec, co oznacza, że sposób jego użycia różni się w różnych usługach, ale podstawowa idea pozostaje niezmienna. WebHooki można traktować jako prosty model pub/sub, gdzie użytkownik może subskrybować zdarzenia zachodzące gdzie indziej. Powiadomienia o zdarzeniach są propagowane jako żądania HTTP POST zawierające informacje o samym zdarzeniu.

Zazwyczaj żądanie HTTP POST zawiera obiekt JSON lub dane formularza HTML określone przez nadawcę elementu webhook, w tym informacje o zdarzeniu powodującym wyzwolenie elementu webhook. Na przykład treść żądania POST webhook z GitHub wygląda tak w rezultacie otwarcia nowego zgłoszenia w konkretnym repozytorium.

{
  "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,
      ...
  }
}

Aby upewnić się, że WebHook rzeczywiście pochodzi od zamierzonego nadawcy, żądanie POST jest zabezpieczone w określony sposób, a następnie zweryfikowane przez odbiorcę. Na przykład Webhook GitHub zawiera nagłówek HTTP X-Hub-Signature z hash wartości treści żądania, który jest sprawdzany przez implementację odbiornika, dzięki czemu nie musisz się tym martwić.

Przepływ webhooka zazwyczaj wygląda następująco:

• Nadawca WebHooka uwidacznia zdarzenia, na które klient może się zapisać. Zdarzenia opisują zauważalne zmiany w systemie, na przykład, że nowy element danych został wstawiony, czy proces został ukończony lub coś innego.

• Odbiornik WebHook subskrybuje przez zarejestrowanie WebHooku składającego się z czterech części:

  1. URI, na który należy opublikować powiadomienie o zdarzeniu w postaci żądania HTTP POST;

  2. Zestaw filtrów opisujących określone zdarzenia, dla których WebHook powinien zostać uruchomiony.

  3. Klucz tajny używany do podpisywania żądania HTTP POST;

  4. Dodatkowe dane, które mają zostać uwzględnione w żądaniu HTTP POST. Może to być na przykład dodatkowe pola nagłówka HTTP lub właściwości zawarte w treści żądania HTTP POST.

• Po wystąpieniu zdarzenia zostaną znalezione pasujące rejestracje WebHook, a żądania HTTP POST zostaną przesłane. Zazwyczaj generowanie żądań HTTP POST jest ponawiane kilka razy, jeśli z jakiegoś powodu adresat nie odpowiada lub żądanie HTTP POST powoduje wystąpienie błędu.

Proces przetwarzania WebHooks

Potok przetwarzania WebHooks w ASP.NET od Microsoft dla przychodzących WebHooks jest następujący:

Oto dwa kluczowe pojęcia: Odbiorniki i programy obsługi:

• Odbiorcy są odpowiedzialni za obsługę określonego typu WebHooka od danego nadawcy i przeprowadzanie kontroli zabezpieczeń, aby upewnić się, że żądanie WebHooka rzeczywiście pochodzi od zamierzonego nadawcy.

• Obsługiwacze to zwykle miejsce, w którym kod użytkownika odpowiada za przetwarzanie danego WebHooka.

W poniższych węzłach te pojęcia zostały opisane bardziej szczegółowo.