В чём разница между PUT, POST и DELITE?

Разница между методами HTTP: PUT, POST и DELETE

В протоколе HTTP методы PUT, POST и DELETE являются ключевыми операциями для управления ресурсами в RESTful API. Они относятся к CRUD-операциям (Create, Read, Update, Delete) и имеют чёткую семантику, определённую в спецификации HTTP (RFC 7231). Понимание их различий критически важно для проектирования корректного и предсказуемого API, а также для тестирования его работы.

Семантика и идемпотентность

Основное различие между методами заключается в их семантике (предназначении) и свойстве идемпотентности.

• Идемпотентность означает, что многократное выполнение одного и того же запроса с одинаковыми данными должно приводить к одному и тому же результату на сервере. Это ключевое свойство для обеспечения надёжности и предсказуемости API, особенно при сбоях сети и автоматических повторах запросов.

Метод POST (Create)

Метод POST используется для создания нового ресурса, когда клиент заранее не знает его идентификатора (URI). Он также может применяться для выполнения сложных операций, не укладывающихся в простую модель CRUD.

• Назначение: Создание. Чаще всего для создания дочернего ресурса в коллекции.
• Идемпотентность: НЕ идемпотентен. Повторная отправка одного и того же POST-запроса, как правило, приводит к созданию нескольких новых, дублирующих друг друга ресурсов.
• Типичные коды ответа: 201 Created (успех), 400 Bad Request (невалидные данные), 409 Conflict (конфликт, например, дубликат).
• Пример запроса:

  POST /api/users HTTP/1.1
  Host: example.com
  Content-Type: application/json
  
  {"name": "Иван", "email": "ivan@mail.com"}
  

• Ожидаемый ответ при успехе:

  HTTP/1.1 201 Created
  Location: /api/users/123
  Content-Type: application/json
  
  {"id": 123, "name": "Иван", "email": "ivan@mail.com"}
  

    Сервер создал пользователя с ID=123 и сообщил клиенту его URI в заголовке `Location`.

Метод PUT (Update / Replace)

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

• Назначение: Полное обновление (замена) ресурса.
• Идемпотентность: Идемпотентен. Десять идентичных PUT-запросов подряд должны оставить ресурс в том же состоянии, что и один запрос.
• Типичные коды ответа: 200 OK или 204 No Content (успешное обновление), 201 Created (если ресурс был создан), 404 Not Found (если ресурс не существует и сервер не поддерживает его создание через PUT).
• Пример запроса для обновления:

  PUT /api/users/123 HTTP/1.1
  Host: example.com
  Content-Type: application/json
  
  {"name": "Иван Обновлённый", "email": "newivan@mail.com"}
  

    Этот запрос **полностью заменит** все данные пользователя с ID=123 на новые. Если у пользователя было поле `age`, оно будет удалено, так как не было передано в запросе.

Метод DELETE (Delete)

Метод DELETE используется для удаления ресурса по указанному URI.

• Назначение: Удаление ресурса.
• Идемпотентность: Идемпотентен. Удаление несуществующего ресурса (404 Not Found) и удаление уже удалённого ресурса (404 Not Found или 204 No Content) — это, по сути, один и тот же конечный результат (ресурса нет). Поэтому повторные DELETE-запросы безопасны.
• Типичные коды ответа: 204 No Content (успешное удаление, тело ответа пустое), 200 OK (удаление прошло успешно, в теле может быть информация об удалённом объекте), 404 Not Found (ресурс не найден), 202 Accepted (запрос принят, но удаление будет выполнено асинхронно).
• Пример запроса:

  DELETE /api/users/123 HTTP/1.1
  Host: example.com
  

Сводная таблица различий

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

1. Тестирование идемпотентности: Для PUT и DELETE необходимо обязательно проверять сценарии с повторной отправкой одинаковых запросов. Ожидается, что состояние системы после первого и N-го запроса будет идентичным. Для POST повторная отправка, скорее всего, создаст дубликаты, что может быть как ожидаемым, так и ошибочным поведением (требуется проверка согласно спецификации API).
2. Валидация ответов: Коды состояния (Status Codes) для этих методов должны соответствовать их семантике. Например, успешное создание через POST должно возвращать 201, а не 200. Удаление чаще всего возвращает 204.
3. Тестирование граничных условий: Что произойдёт при PUT на несуществующий URI? Что вернёт DELETE для уже удалённого ресурса? Как сервер обработает POST с дублирующимися данными? Ответы на эти вопросы — основа для тест-кейсов.
4. Понимание контракта API: Корректное использование методов — залог правильного взаимодействия клиента и сервера. Ошибка, например, использование PUT вместо POST для создания, может привести к неожиданным side-effects (например, перезаписи другого ресурса). QA должен чётко понимать ожидаемое поведение, описанное в документации.

Таким образом, разница между PUT, POST и DELETE фундаментальна и лежит в плоскости их предназначения, гарантий идемпотентности и безопасности, что напрямую влияет на проектирование, реализацию и, что особенно важно, на тестирование REST API.