Какие методы REST являются идемпотентными
Что проверяют
Знаете ли вы список и понимаете ли, что идемпотентность про состояние, а не про одинаковый ответ.
Как отвечать
Идемпотентные: GET, HEAD, OPTIONS, PUT, DELETE. Не идемпотентные: POST и PATCH в общем случае.
Определение: повторное выполнение с теми же параметрами оставляет систему в том же состоянии, что и однократное. Речь именно про состояние сервера, а не про тело и код ответа. Поэтому повторный DELETE, возвращающий 404 вместо 204, идемпотентности не нарушает: объекта нет и после первого, и после второго вызова.
Отдельно про безопасность: GET, HEAD и OPTIONS ещё и безопасны, то есть вообще не меняют состояние. Все безопасные методы идемпотентны, обратное неверно.
Почему PATCH не идемпотентен: зависит от тела. Замена поля идемпотентна, а инкремент нет.
Практическая ценность прямая: клиент, прокси или очередь могут повторить запрос при таймауте, не зная, дошёл ли он. Идемпотентный повторять безопасно. Для POST этого делать нельзя, поэтому вводят ключ идемпотентности: клиент шлёт уникальный идентификатор запроса, сервер запоминает результат и на повтор возвращает сохранённый ответ. Так работают платёжные системы.
Что проверять тестировщику: отправить запрос дважды и убедиться, что создалась одна сущность; повторить с тем же ключом идемпотентности; проверить параллельную отправку; убедиться, что обработчик события из очереди тоже идемпотентен.
Где спотыкаются
Исключают DELETE из списка из-за другого кода ответа.
Путают безопасность и идемпотентность.
Считают PATCH всегда идемпотентным.
Не проверяют двойную отправку формы и пропускают дубли заказов.