В чем разница между HTTP-методами POST, PUT и PATCH?

С точки зрения тестирования API, понимание семантики этих методов критически важно для корректного написания тестов и валидации поведения системы.

POST используется для создания нового ресурса, когда идентификатор (ID) неизвестен или генерируется сервером. При тестировании мы проверяем, что в ответе приходит код 201 Created, заголовок Location с URI нового ресурса и тело с созданным объектом.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Anna", "email": "anna@example.com"}

PUT предназначен для полной замены ресурса по известному URI (идемпотентная операция). В тестах мы отправляем полное представление ресурса и проверяем код 200 OK (или 201 Created, если ресурс был создан). Последующие идентичные запросы не должны менять состояние системы.

PUT /api/users/123 HTTP/1.1
Content-Type: application/json

{"id": 123, "name": "Anna Updated", "email": "anna.new@example.com"}

PATCH применяет частичные изменения к ресурсу (также идемпотентен). Тестирование PATCH сложнее: нужно проверить, что обновились только переданные поля, а остальные остались неизменными. Часто используется формат JSON Patch.

PATCH /api/users/123 HTTP/1.1
Content-Type: application/json

{"email": "anna.latest@example.com"}

Ключевые аспекты для тестировщика:

1. Идемпотентность: PUT и PATCH при повторении с теми же данными дают тот же результат (код ответа может отличаться, но состояние ресурса — нет). POST — не идемпотентен, каждый вызов создает новый ресурс.
2. Коды ответов: Ожидаем 201 для успешного POST, 200/204 для PUT/PATCH. Важно проверять и негативные сценарии (например, 409 Conflict при попытке создать дубликат через PUT).
3. Валидация: Для PUT необходимо валидировать, что клиент отправил все обязательные поля для полного обновления. Для PATCH — что частичное обновление допустимо для бизнес-логики.