Что такое идемпотентность API?

Что проверяют

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

Как отвечать

Операция идемпотентна, если повторное выполнение с теми же параметрами не меняет состояние системы по сравнению с однократным.

По методам HTTP: GET, PUT, DELETE, HEAD и OPTIONS идемпотентны, POST и PATCH в общем случае нет.

Важная тонкость: речь про состояние, а не про ответ. Повторный DELETE вернёт 404 вместо 204, но состояние то же самое, объект удалён, значит операция идемпотентна.

Зачем это нужно на практике: сеть ненадёжна. Клиент отправил запрос, получил таймаут и не знает, дошёл ли он. Повторить идемпотентный запрос безопасно. Повторить POST на создание платежа значит списать деньги дважды.

Отсюда ключ идемпотентности: клиент генерирует уникальный идентификатор запроса и шлёт его заголовком. Сервер запоминает результат по ключу и на повтор возвращает сохранённый ответ, не выполняя операцию заново. Так работают платёжные шлюзы.

Что проверять тестировщику: отправить один и тот же запрос дважды и убедиться, что создалась одна сущность; повторить с тем же ключом идемпотентности; проверить поведение при параллельной отправке; убедиться, что обработчик события из очереди тоже идемпотентен, потому что доставка обычно «хотя бы один раз».

Где спотыкаются

Считают DELETE неидемпотентным из-за другого кода ответа.

Путают идемпотентность с безопасностью метода: GET и безопасен, и идемпотентен, а DELETE только второе.

Не проверяют повторную отправку формы и пропускают дубли заказов.

Забывают, что повтор возможен не только от пользователя, но и от прокси, ретрая клиента и повторной доставки сообщения.