Идемпотентность — это просто, пока второй запрос не окажется другим
Разбираемся, почему идемпотентность в API — это не просто «повторить тот же запрос», а целая наука с подводными камнями.
Все знают, что идемпотентность — это когда повторный запрос даёт тот же результат, что и первый. Звучит просто, как дважды нажать на кнопку лифта. Но в реальности это скорее напоминает попытку собрать IKEA-шкаф без инструкции: вроде бы те же детали, а результат почему-то разный.
На практике идемпотентность ломается, когда второй запрос приходит с другими данными. Например, если клиент отправляет тот же идентификатор идемпотентности, но с изменённым телом запроса. Сервер должен решить: игнорировать новое тело или обработать его как новый запрос? И то, и другое может привести к неожиданным последствиям.
Автор статьи разбирает типичные сценарии: от простого повторного POST до сложных случаев с частичными обновлениями. Особенно больно, когда в игру вступают распределённые системы — тут уже не до шуток, каждый лишний запрос может вызвать каскад ошибок, как если бы вы случайно отправили письмо с критическим багом всем клиентам.
Главный вывод: идемпотентность — это не просто протокол, а архитектурное решение. Если вы думаете, что достаточно добавить поле idempotency_key в базу, то вас ждёт сюрприз. Как и в случае с ночным деплоем, лучше семь раз отмерить, чем потом разбирать прод-инцидент в 3 часа ночи.
Комментарий студии METABYTE: Идемпотентность — это та тема, которую многие разработчики откладывают «на потом», пока не столкнутся с дублирующимися платежами или сломанным заказом. Мы в METABYTE всегда закладываем идемпотентность в архитектуру с самого начала — это дешевле, чем потом объяснять клиенту, почему у него списалось дважды.