Обзор веб-перехватчиков #REF!

Предупреждение

#REF! WebHooks устаревший и больше не будет получать обновления или патчи безопасности.

WebHooks — это упрощенный шаблон HTTP, предоставляющий простую модель pub/sub для объединения веб-API и служб SaaS. Когда событие происходит в службе, уведомление отправляется в виде HTTP-запроса POST зарегистрированным подписчикам. Запрос POST содержит сведения о событии, которые позволяют получателю действовать соответствующим образом.

Благодаря простоте веб-перехватчики уже предоставляются большим количеством служб, включая Dropbox, #REF!, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello и многое другое. Например, веб-перехватчик может указать, что файл изменился в Dropbox, или изменение кода было зафиксировано в #REF!, или платеж был инициирован в PayPal или карточка была создана в Trello. Возможности бесконечны!

Microsoft #REF! WebHooks упрощает отправку и получение WebHooks в составе вашего приложения #REF!.

• На принимающей стороне она предоставляет общую модель для получения и обработки вебхуков от любых поставщиков вебхуков. Он выходит из коробки с поддержкой Dropbox, #REF!, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello, WordPress и Zendesk, но легко добавить поддержку для других.

• Отправляющая сторона предоставляет поддержку управления и хранения подписок, а также отправку уведомлений о событиях нужным подписчикам. Это позволяет определить собственный набор событий, на которые подписчики могут подписываться и уведомлять их о том, когда это происходит.

Две части можно использовать вместе или отдельно в зависимости от вашего сценария. Если вам нужно только получать WebHooks от других служб, вы можете использовать только компонент получателя; если вы хотите предоставлять WebHooks для других служб, вы можете делать только это.

Код предназначен для веб-API ASP.NET 2 и #REF! 5 и доступен как OSS на #REF!.

Обзор WebHooks

ВебHooks — это образец, который подразумевает, что его используют по-разному в зависимости от службы, но основная идея остается неизменной. Веб-хуки можно рассматривать как простую модель pub/sub, где пользователь может подписаться на события, происходящие где-либо еще. Уведомления о событиях распространяются как HTTP-запросы POST, содержащие сведения о самом событии.

Обычно HTTP-запрос POST содержит объект JSON или данные формы HTML, определенные отправителем веб-перехватчика, включая сведения о событии, вызывающего триггер веб-перехватчика. Например, текст запроса WebHook POST из #REF! выглядит следующим образом в результате новой проблемы, открываемой в определенном репозитории:

{
  "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 защищается одним из способов, а затем проверяется получателем. Например, #REF! WebHooks включает в HTTP заголовок X-Hub-Signature хэш тела запроса, который проверяется реализацией приемника, чтобы вам не нужно было об этом беспокоиться.

Поток веб-хука обычно идет примерно так:

• Отправитель веб-хука предоставляет события, на которые клиент может подписаться. События описывают наблюдаемые изменения в системе, например вставленный новый элемент данных, завершенный процесс или что-то другое.

• Получатель веб-хука подписывается путем регистрации веб-хука, состоящего из четырех элементов:

  1. URI, где уведомление о событии должно быть отправлено в виде HTTP POST-запроса;

  2. Набор фильтров, описывающих определенные события, для которых должен быть запущен веб-перехватчик;

  3. Секретный ключ, который используется для подписывания HTTP-запроса POST;

  4. Дополнительные данные, которые необходимо включить в HTTP-запрос POST. Это может быть дополнительное поле заголовка HTTP или свойства, включенные в текст ЗАПРОСА HTTP POST.

• После того как событие произойдет, будут найдены соответствующие регистрации вебхуков, и запросы HTTP POST отправляются. Как правило, создание HTTP-запросов POST выполняется несколько раз, если по какой-то причине получатель не отвечает, или HTTP-запрос POST приводит к возникновению ошибки.

Конвейер обработки вебхуков

Конвейер обработки Microsoft #REF! WebHooks для входящих WebHooks выглядит следующим образом:

Ниже приведены два основных понятия приемников и обработчиков:

• Получатели отвечают за обработку определенного типа веб-перехватчика от заданного отправителя и применение мер безопасности, чтобы убедиться, что запрос веб-перехватчика действительно поступил от предполагаемого отправителя.

• Обработчики — это по сути место, где пользовательский код обрабатывает определенный WebHook.

В следующих узлах эти понятия описаны более подробно.