omówienie elementów webhook ASP.NET

Elementy WebHook to lekki wzorzec HTTP zapewniający prosty model pub/sub do łączenia interfejsów API sieci Web i usług SaaS. Gdy zdarzenie występuje 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ę elementy webhook są już udostępniane przez dużą liczbę 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 uległ zmianie w usłudze Dropbox lub wprowadzono zmianę kodu w usłudze GitHub lub zainicjowano płatność w usłudze PayPal lub w witrynie Trello utworzono kartę. Możliwości są nieskończone!

Elementy webhook firmy Microsoft ASP.NET ułatwiają wysyłanie i odbieranie elementów WebHook w ramach aplikacji ASP.NET:

• Po stronie odbieranej udostępnia typowy model odbierania i przetwarzania elementów WebHook z dowolnej liczby dostawców elementów webhook. Wychodzi z pudełka z obsługą Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello, WordPress i Zendesk , ale łatwo jest dodać obsługę więcej.

• 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ń, które subskrybenci mogą subskrybować i powiadamiać o tym, kiedy 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ć elementy WebHook z innych usług, możesz użyć tylko części odbiornika; jeśli chcesz uwidocznić elementy webhook dla innych użytkowników do użycia, możesz to zrobić.

Kod jest przeznaczony dla ASP.NET internetowego interfejsu API 2 i ASP.NET MVC 5 i jest dostępny jako system operacyjny w usłudze GitHub.

Elementy webhook — omówienie

Elementy webhook to wzorzec, który oznacza, że różni się w zależności od sposobu jej użycia z usługi do usługi, ale podstawowy pomysł jest taki sam. Elementy WebHook można traktować jako prosty model pub/pod model, w którym użytkownik może subskrybować zdarzenia dzieje się 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 elementu WebHook z usługi GitHub wygląda następująco w wyniku otwarcia nowego problemu w określonym 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 element WebHook jest rzeczywiście od zamierzonego nadawcy, żądanie POST jest zabezpieczone w jakiś sposób, a następnie zweryfikowane przez odbiorcę. Na przykład elementy WebHook w usłudze GitHub zawierają nagłówek HTTP X-Hub-Signature z skrótem treści żądania, który jest sprawdzany przez implementację odbiorcy, aby nie martwić się o to.

Przepływ elementu webhook zwykle wygląda następująco:

• Nadawca elementu webhook ujawnia zdarzenia, do których klient może subskrybować. Zdarzenia opisują widoczne zmiany w systemie, na przykład, że nowy element danych został wstawiony, że proces został ukończony lub coś innego.

• Odbiornik elementu WebHook subskrybuje, rejestrując element WebHook składający się z czterech elementów:

  1. Identyfikator URI, dla którego powiadomienie o zdarzeniu powinno być publikowane w postaci żądania HTTP POST;

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

  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 zakończeniu zdarzenia zostaną znalezione pasujące rejestracje elementu 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 błąd odpowiedzi.

Potok przetwarzania elementów webhook

Potok przetwarzania elementów webhook firmy Microsoft ASP.NET dla przychodzących elementów webhook wygląda następująco:

Poniżej przedstawiono dwa kluczowe pojęcia: Odbiorniki i programy obsługi:

• Odbiorcy są odpowiedzialni za obsługę konkretnego smaku elementu WebHook od danego nadawcy i wymuszania kontroli zabezpieczeń w celu zapewnienia, że żądanie elementu webhook rzeczywiście pochodzi od zamierzonego nadawcy.

• Programy obsługi są zwykle miejscem, w którym kod użytkownika uruchamia przetwarzanie określonego elementu WebHook.

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