Вебхуки: получайте события без повторения действий

Кратко

Вебхук уведомляет о событии по HTTP. Он не гарантирует универсально мгновенную доставку, порядок или ровно однократный бизнес-эффект.

Пустой защищённый коридор серверов и сетевого оборудования
В этой статье

Разделять приём и завершённую обработку

Гарантии зависят от поставщика. Stripe описывает возможные дубли и отсутствие гарантии порядка. Успешный HTTP-ответ должен соответствовать устойчивому приёму или нужной обработке, а не лишь запросу в памяти.

СитуацияОжидаемое поведениеПолезное свидетельство
Одно событие дваждыНе допустить повторный бизнес-эффект.Обработанный ID и сохранённый результат.
Старое событие приходит позжеНе затирать новое состояние вслепую.Авторитетное состояние и правило перехода.
Тяжёлая обработкаУстойчивый приём и отложенная работа.Состояние очереди и результат обработчика.
Нет доставкиСверить и восстановить по правилам поставщика.Выявленный разрыв и проверенное исправление.

Построить проверяемый приём

  • Проверяйте HTTPS, подпись и защиту от повтора по протоколу поставщика. Stripe проверяет подпись по исходному телу; предварительное преобразование JSON может нарушить проверку.
  • Сохраняйте событие или обработку устойчиво до соответствующего подтверждения. Различайте ID доставки, ID события и ключ идемпотентности действия.
  • Тестируйте дубли, нарушенный порядок, прерывание и перезапуск обработчика. Читайте авторитетное состояние объекта, если старое событие не даёт безопасного решения.

Организовать восстановление и сверку

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

Первоисточники

Безопасная обработка повторяющихся веб-хуков.

Уведомление может быть повторено после тайм-аута или потери ответа. Надежность зависит от проверки источника, идентификатора события и обработки, которая отделяет новое сообщение от дубликата.

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

Первичный источник: IETF RFC 9457 — Problem Details for HTTP APIs. Связанный метод: прочитать практическое руководство.