Являются ли идемпотентными POST, PUT и PATCH

Ответ на вопрос об идемпотентности HTTP1-методов

Введение в идемпотентность

В контексте HTTP1-методов идемпотентность означает свойство, при котором многократное выполнение одной и той же операции с одинаковыми данными приводит к одному и тому же результату, что и однократное выполнение. Это критически важное свойство для обеспечения надежности распределенных систем, особенно при обработке сетевых ошибок и повторных запросов.

Анализ методов POST, PUT и PATCH

1. Метод POST — НЕ идемпотентен

Метод POST предназначен для создания нового ресурса. Каждый повторный запрос POST с одинаковыми данными, как правило, создает новые сущности, что приводит к разному состоянию системы.

• Пример: Отправка запроса на создание заказа.

  POST /api/orders
  Content-Type: application/json
  
  {"productId": 123, "quantity":-POST /api/orders
  Content-Type: application/json
  
  {"productId": 123, "quantity": 2}
  

    Первый вызов создаст заказ с ID=101. Второй, идентичный вызов (например, из-за таймаута и автоматического повтора) создаст еще один заказ с ID=102. Состояние системы изменилось, результат не эквивалентен однократному выполнению.

2. Метод PUT — Идемпотентен (в идеальном случае)

Метод PUT предназначен для полного обновления или создания ресурса по известному URI. Его идемпотентность основывается на концепции "полной замены". Клиент отправляет новое представление ресурса, которое должно полностью заменить существующее.

• Условие идемпотентности: Результат должен быть одинаковым независимо от того, был ли ресурс создан или перезаписан, и сколько раз операция была выполнена.
• Пример обновления пользователя:

  PUT /api/users/456
  Content-Type: application/json
  
  {"name": "Ivan", "email": "ivan@test.ru"}
  

    Первый вызов создаст или обновит пользователя с ID=456 до указанного состояния. Любой последующий идентичный вызов будет "перезаписывать" ресурс тем же самым состоянием. Конечный результат будет эквивалентен однократному выполнению.

• Важное замечание: PUT может быть неидемпотентным на практике, если серверная логика выходит за рамки простой замены (например, генерирует новые метки времени или изменяет связанные данные при каждом вызове). Согласно спецификации RFC 7231, PUT должен быть идемпотентным с точки зрения клиента.

3. Метод PATCH — НЕ гарантированно идемпотентен

Метод PATCH предназначен для частичного обновления ресурса. Его идемпотентность напрямую зависит от формата патча и серверной логики его применения.

• Неидемпотентный пример: Патч-операция на увеличение счетчика.

  PATCH /api/articles/789
  Content-Type: application/json
  
  {"op": "increment", "path": "/views", "value": 1}
  

    Каждый повторный вызов будет увеличивать значение поля `views` на 1. Результат после N вызовов отличается от результата после одного вызова.

• Идемпотентный пример: Патч-операция на установку конкретного значения.

  PATCH /api/articles/789
  Content-Type: application/json
  
  {"op": "replace", "path": "/title", "value": "Новое название"}
  

    Многократная отправка этого патча установит поле `title` в одно и то же значение "Новое название". Результат будет идемпотентным.

• Стандарт JSON Patch (RFC 6902) определяет операции, среди которых есть как идемпотентные (replace, add для существующего пути), так и неидемпотентные (test, move в некоторых контекстах). Поэтому в общем случае PATCH не считается идемпотентным методом.

Резюме и выводы для QA Automation

Для автоматизатора понимание идемпотентности ключево при:

• Проектировании тестов на надежность и отказоустойчивость.
• Тестировании сценариев с повторными запросами (например, при таймаутах или ошибках сети 5xx).
• Валидации корректности API согласно RESTful-принципам и RFC.

Итоговая таблица:

На практике всегда следует уточнять контракт API, который вы тестируете. Например, в документации может быть явно указано: "Эндпоинт PATCH /api/resource является идемпотентным", что накладывает обязательства на серверную реализацию.