Что значит, что PUT является идемпотентным методом

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

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

Как отвечать

Идемпотентный метод это метод, у которого эффект нескольких одинаковых запросов на состояние сервера такой же, как у одного. Про тела ответов речь не идёт: первый PUT может вернуть 201 и заголовок Location, второй 200 или 204, и метод остаётся идемпотентным.

Полезно сразу развести свойства:

• GET, HEAD, OPTIONS безопасны, то есть не меняют состояние, и идемпотентны;
• PUT и DELETE идемпотентны, но не безопасны;
• POST не даёт ни того ни другого;
• PATCH идемпотентным не гарантируется, зависит от формата патча.

Проверки, которые стоит назвать: отправить один и тот же PUT дважды и сравнить состояние ресурса через GET, убедиться, что не появилось дубля в связанных таблицах и второго письма; проверить PUT по несуществующему идентификатору, спецификация допускает создание ресурса; оборвать соединение и повторить запрос; послать два одинаковых запроса параллельно. Отдельно проверяется защита от потерянного обновления через ETag и If-Match.

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

Путают идемпотентность с безопасностью и говорят, что PUT ничего не портит. Он меняет данные, просто повтор не умножает изменение. Безопасный метод состояние не трогает вовсе, это разные свойства.

Проверяют только код ответа. Второй запрос вернул 200, значит всё хорошо. Смотреть надо состояние системы целиком: побочные эффекты обычно вылезают не в ответе, а в соседней таблице, в очереди или в почте пользователя.

Требуют побайтовой неизменности и заводят баг на то, что поле с временем обновления изменилось. Идемпотентность про целевое состояние ресурса, служебные поля версии и времени меняться могут. Дефект начинается там, где повтор порождает новую сущность или новое событие.