200 OK не гарантирует успешное завершение операции? В интеграциях есть одна очень коварная вещь, которая становится причиной огромного количества проблем. Сервис вернул
200 OK, и все решили, что операция успешно завершилась.Хотя на самом деле это может быть вообще не так. Важно понимать, что HTTP-ответ показывает только результат обработки конкретного запроса конкретным сервисом.
Он не гарантирует, что весь бизнес-процесс дошёл до конца.
Особенно это становится заметно в распределённых системах, где одна операция почти никогда не ограничивается одним действием.
Давайте вернемся к нашему примеру оформления заказа. Когда пользователь нажимает «купить» система должна создать оплату, зарезервировать товар,
создать доставку, обновить CRM, отправить уведомление и записать событие в аналитику.
Что может произойти?
Сервис заказов может успешно сохранить заказ и вернуть
200 ОК, но платёжный сервис может не ответить, событие может не дойти до очереди, а внешний сервис вообще может быть временно недоступен.С точки зрения HTTP всё хорошо, а вот с точки зрения бизнеса операция выполнена только частично.
Именно поэтому в распределённых системах очень важно разделять успешную обработку запроса и успешное завершение бизнес-операции.
Это две совершенно разные вещи.
И кстати, здесь мы видим, почему интеграции – это не «просто API». Проблемы возникают не в момент успешного запроса. Проблемы возникают между сервисами!
И если в системе не продуманы промежуточные состояния, механизмы восстановления и обработка частичных отказов, со временем начинают появляться
дубли операций, рассинхрон статусов, «пропавшие» действия, плавающие баги,
которые невозможно воспроизвести.
Поэтому мой совет всем, кто только учиться проектировать интеграции – смотрите не только на ответ API, а на полный жизненный цикл операции от первого запроса до момента, когда система действительно пришла в корректное конечное состояние.