Используется ли только POST метод для создания, изменения и редактирования
Что проверяют
Понимаете ли вы семантику HTTP-методов и умеете ли превратить её в проверки: какой ответ ожидать и что будет при повторе запроса. Следом обычно спрашивают про идемпотентность и чем PUT отличается от PATCH на практике.
Как отвечать
Короткий ответ: нет. По семантике HTTP (RFC 9110) для изменения данных есть несколько методов:
- POST: создание ресурса в коллекции (
POST /users) или произвольное действие. Не идемпотентен: два одинаковых запроса создадут две записи. Типичный ответ201 Createdс заголовкомLocation; - PUT: полная замена ресурса по известному адресу, может и создать его. Идемпотентен: повтор оставляет то же состояние. Поля, которых нет в теле, по смыслу должны пропасть;
- PATCH (RFC 5789): частичное изменение. Формат тела зависит от API, часто это JSON Merge Patch или JSON Patch. Идемпотентность не гарантирована;
- DELETE: удаление, идемпотентен по состоянию, хотя повторный вызов может вернуть
404.
Дальше главное для тестировщика: спецификация описывает, как правильно, а реальный API может работать иначе. Многие API построены в RPC-стиле и шлют всё через POST, GraphQL тоже обычно ходит POST на один адрес. Источник истины для тестов это контракт (OpenAPI, документация), и проверки строятся от него:
- повтор PUT: не создаёт дублей и не меняет результат;
- PATCH: меняет только переданные поля и не обнуляет остальные;
- чужой метод: неподдерживаемый метод отвечает
405 Method Not Allowed; - повтор POST: если API поддерживает заголовок
Idempotency-Key, повтор после сетевого сбоя не создаёт дубль.
Проверять удобно в Postman, curl, REST Assured или pytest с requests.
Где спотыкаются
Отправляют в PUT одно поле и считают это нормой. По семантике это замена ресурса целиком, и если API так и работает, остальные поля пропадут.
Путают безопасность и идемпотентность. Безопасные методы в терминах HTTP не меняют состояние: GET, HEAD, OPTIONS. PUT идемпотентен, но безопасным не является.
Заводят баг на то, что обновление сделано через POST. Это отступление от REST, но не дефект, если так записано в контракте.