Что будет если PUT отправить несколько раз?

Поведение HTTP-метода PUT при многократном вызове

Если отправить HTTP-запрос с методом PUT несколько раз подряд на один и тот же ресурс, результат будет идемпотентным. Это означает, что повторение одного и того же запроса с одинаковыми данными приведёт к одинаковому результату на сервере, как если бы он был выполнен только один раз (при условии отсутствия параллельных изменений со стороны других клиентов).

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

• Создание или полная замена: Метод PUT используется для создания нового ресурса по указанному URI или для полного обновления (замены) существующего. Если ресурс существует, тело запроса полностью заменяет его текущее состояние.
• Одинаковый результат: Выполнение PUT /users/123 { "name": "Alice" } 1 раз или 5 раз подряд (с идентичным телом запроса) оставит ресурс в конечном счёте в одном и том же состоянии: ресурс /users/123 будет содержать { "name": "Alice" }. Повторные запросы не создадут несколько копий ресурса.
• Важность статус-кодов: Хотя конечное состояние ресурса одинаково, коды ответа HTTP могут различаться между первым и последующими вызовами, что важно для тестирования API:

    *   **Первый успешный вызов** (ресурс создан): обычно возвращает статус **`201 Created`**.
    *   **Последующие успешные вызовы** (ресурс обновлён): обычно возвращают статус **`200 OK`** или **`204 No Content`**.

Пример для наглядности

Представим, что у нас есть REST API для управления статьями.

1. Первый вызов PUT (создание):

PUT /articles/1 HTTP/1.1
Content-Type: application/json

{
    "title": "Моя первая статья",
    "body": "Содержание статьи..."
}

Ответ:

HTTP/1.1 201 Created
Location: /articles/1

2. Второй идентичный вызов PUT (обновление тем же содержимым):

PUT /articles/1 HTTP/1.1
Content-Type: application/json

{
    "title": "Моя первая статья",
    "body": "Содержание статьи..."
}

Ответ:

HTTP/1.1 200 OK

Или:

HTTP/1.1 204 No Content

Практическое значение для QA Engineer

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

1. Тестирование идемпотентности: Мы должны явно проверять, что повторные PUT-запросы:

    *   Не создают дублирующих ресурсов.
    *   Не вызывают сторонних нежелательных эффектов (например, многократного списания средств, если бизнес-логика неверно реализована).
    *   Возвращают корректные и ожидаемые статус-коды (`201` при создании, `200/204` при обновлении).

1. Тестирование параллельных запросов (Race Conditions): Идемпотентность не означает атомарность или защиту от состояний гонки. Если два PUT-запроса с разными данными отправлены почти одновременно к одному ресурсу, может возникнуть состояние гонки (race condition). Финальное состояние ресурса будет определяться тем, чей запрос обработается последним. Это требует отдельного тестирования.

2. Отличие от POST: Важно контрастировать это с методом POST, который является неидемпотентным. Каждый вызов POST /articles с одинаковым телом создаст новую, отдельную статью, что вернёт 201 Created и новый уникальный URI (например, /articles/2, /articles/3 и т.д.).

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

Вывод для собеседования: Многократная отправка идентичных PUT-запросов является безопасной операцией с точки зрения конечного состояния ресурса благодаря идемпотентности метода. Однако, задача QA — не только знать эту теорию, но и уметь проектировать тесты, которые проверяют корректную реализацию этого поведения на практике, включая обработку статус-кодов и потенциальных состояний гонки при конкурентных запросах.