Какие методы являются неидемпотентными?

Неидемпотентные HTTP-методы

Идемпотентность — это ключевое свойство HTTP-метода, означающее, что многократное выполнение одного и того же запроса с одинаковыми данными приводит к одинаковому результату на сервере и не вызывает побочных эффектов, кроме тех, что были при первом выполнении. Неидемпотентные методы — это методы, повторение которых может изменять состояние сервера каждый раз и приводить к разным результатам.

Список основных неидемпотентных методов

В соответствии со стандартом HTTP/1.1 (RFC 7231), к неидемпотентным методам относятся:

• POST (Создание): Используется для создания новых ресурсов или выполнения действий с побочными эффектами. Каждый повторный запрос, как правило, создает новый объект или запускает процесс заново.

    *   *Пример*: `POST /api/users` с телом `{"name": "Alice"}` при каждом вызове будет создавать нового пользователя "Alice" с новым уникальным ID.

• PATCH (Частичное обновление): Предназначен для частичного обновления ресурса. Его идемпотентность зависит от реализации. Если операция PATCH является неидемпотентной по своей природе (например, инкремент счетчика), то повторные вызовы будут давать разный результат.

    *   *Пример неидемпотентного PATCH*:

    ```http
    PATCH /api/articles/123
    Content-Type: application/json-patch+json

    [
        { "op": "inc", "path": "/views", "value": 1 }
    ]
    ```

        Каждый вызов этого запроса будет увеличивать количество просмотров статьи на 1.

• Некоторые кастомные методы или действия, выходящие за рамки CRUD, например:

    *   `POST /api/transfer` (перевод денег).
    *   `POST /api/emails/send` (отправка email).

Почему эти методы неидемпотентны? Сравнение с идемпотентными

Чтобы понять разницу, сравним с ключевыми идемпотентными методами:

1. GET, HEAD, OPTIONS, TRACE: Только читают данные, не изменяя состояние сервера. Их можно вызывать сколько угодно раз без риска.
2. PUT (Полное замещение): Идемпотентен, так как повторная отправка одного и того же тела запроса полностью замещает ресурс, возвращая его в одно и то же конечное состояние.

   PUT /api/users/456
   Content-Type: application/json
   
   {"name": "Bob", "age": 30}
   

    Сколько бы раз мы ни отправили этот запрос, пользователь с ID 456 всегда будет иметь имя "Bob" и возраст 30.

1. DELETE (Удаление): Идемпотентен. После первого успешного удаления ресурса (код ответа 200 или 204) последующие вызовы обычно возвращают 404 (Not Found) или 410 (Gone), что означает одинаковое конечное состояние системы — ресурс отсутствует.

POST, в отличие от PUT, не гарантирует идемпотентности. Даже если отправить два абсолютно одинаковых запроса POST /api/orders, в большинстве корректных систем будут созданы два отдельных заказа с разными идентификаторами.

Практическое значение для тестирования и разработки API

Понимание идемпотентности критично для:

• Надежности и безопасности: Клиенты (браузеры, мобильные приложения) могут безопасно повторять идемпотентные запросы (например, при таймауте или потере соединения), не опасаясь дублирования операций. Для неидемпотентных запросов нужны дополнительные механизмы (токены идемпотентности, подтверждения).
• Тест-дизайна (QA):

    *   При тестировании **неидемпотентных методов** необходимо обязательно проверять **сценарии повторной отправки** (double-submit). Это проверяет, как система защищена от дублирующих действий: создаются ли дубликаты сущностей, списываются ли средства дважды?
    *   Для идемпотентных методов можно смело выполнять нагрузочное тестирование с повторением одних и тех же запросов.

• Проектирования API: Если операция должна быть безопасной для повтора (например, применение купона к заказу), ее лучше спроектировать как идемпотентную, используя PUT или идемпотентный PATCH, либо реализовав механизм идемпотентных ключей (Idempotency-Key) для POST-запросов.

Вывод

Таким образом, основными неидемпотентными методами являются POST и, в зависимости от семантики операции, PATCH. Их повторное выполнение потенциально ведет к изменению состояния системы каждый раз по-новому. Это фундаментальное свойство, которое напрямую влияет на проектирование, тестирование и отказоустойчивость веб-сервисов.