Начнём с очевидного: надёжные сервисы обычно повторяют доставку вебхука, если первая попытка завершилась неудачно. Однако здесь есть две важные проблемы.
Во-первых, не все сервисы повторяют доставку вебхуков после сбоя. Во-вторых, даже при наличии повторных попыток они выполняются по внутреннему расписанию отправителя. Вы не можете управлять количеством попыток, интервалами между ними и временем следующей доставки.
Если проблема с сетью, перезапуск сервера или выключение ноутбука совпадут с периодом повторных попыток, вебхук всё равно может быть потерян.
Одни поставщики используют очень короткие интервалы между попытками, а другие ограничивают их общее количество. В результате вы полностью зависите от политики доставки отправителя и не можете управлять доставкой вебхуков со своей стороны.
Возникает практический вопрос: как управлять повторными попытками, если вы не контролируете сервис, который отправляет вебхуки?
Решение — получать вебхуки через Adal.
Получив вебхук, Adal сохраняет исходный запрос и позволяет вам управлять его дальнейшей обработкой. Вы можете повторить доставку настроенным получателям, просмотреть полученный запрос, изучить его заголовки и тело, а также имитировать повторное получение того же вебхука с параметрами исходного запроса.
Представьте, что вы тестируете обработку платежей, но локальный сервер выключен именно в тот момент, когда платёжный сервис отправляет вебхук. Без промежуточного уровня запрос может быть потерян или повторно отправлен только по правилам самого сервиса. Adal сначала принимает и сохраняет вебхук. После этого вы сами решаете, когда и куда доставить его повторно.
Так работа с вебхуками становится надёжнее при локальной разработке, нестабильном сетевом соединении, простое сервера и временных проблемах с инфраструктурой.