обработка данных о неудачном вызове URL-адреса webhook - PullRequest
1 голос
/ 07 февраля 2012

Мой продукт SaaS публикует уведомления о событиях в виде веб-крючков.Этот вопрос касается обработки случаев сбоя при публикации в URL-адресе веб-крюка.

В случае неполучения кода ответа 200 OK с URL-адреса, на который я отправляю данные о событии, я отмечаю уведомление о событии как сбойное и запускаюпроцесс повторной попытки.В настоящее время я храню идентификаторы данных, которые я должен отправить как часть данных о событии, и извлекаю их из БД для каждой повторной попытки.

Я просто хотел посмотреть, как другие справятся с этим?Еще одна вещь, о которой я могу подумать, это сохранить фактическую полезную нагрузку (в формате JSON или XML) в БД и отправлять ее при каждой повторной попытке.Но как вы ожидаете, что получатель событий будет обрабатывать проблемы синхронизации данных, которые могут возникнуть из-за этого?

1 Ответ

2 голосов
/ 09 февраля 2012

Похоже, вам нужно дать получателю webhook возможность выбрать, следует ли повторно отправлять данные POST, когда они регистрируют свою конечную точку в вашем сервисе.Я также настоятельно рекомендую предоставить четкую документацию о том, как ваша служба обрабатывает различные коды ответов.

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

Кроме того, учтите следующее: что произойдет, если ваш сервис выйдет из строя.Если синхронизация важна, как ваша служба и конечная точка решают эту проблему?

Вы не предоставили слишком много контекста для того, какие данные вы отправляете и каких именно проблем синхронизации вы боитесь.Можете поделиться еще?

Отредактировано : Вот , как MailChimp обрабатывает эту проблему .Они явно находятся в той же лодке, что и вы.

Когда произойдет событие, которое вы включили, мы отправим запрос HTTP POST на URL, который вы 'мы указали.Если этот URL-адрес недоступен или ответ занимает слишком много времени (более 15 секунд), мы отменим запрос и повторим попытку позже.Повторные попытки выполняются с увеличивающимися интервалами в течение 1 часа и 15 минут.Эти временные рамки могут быть изменены, когда мы начнем получать отзывы от пользователей.

Для каждого события мы будем возвращать различные данные, основанные на событии.Ниже приведен пример данных для каждого события - вы также можете легко увидеть это с помощью инструмента PostBin, упомянутого выше.Вообще говоря, вы увидите, что каждое событие имеет тип и поле fired_at, чтобы помочь вам отследить тип события и получить метку времени (в GMT!) Для события.

...