Какие методы в REST существуют и с какими работали
Что проверяют
Знаете ли вы про безопасность и идемпотентность методов, а не только «GET читает, POST создаёт». Для тестировщика это вопрос про сценарии повторов и сбоев: что будет, если клиент отправит запрос дважды. Следом спрашивают разницу PUT и PATCH и что должен вернуть повторный DELETE.
Как отвечать
Сначала классификация, она даёт каркас. Безопасные методы не меняют состояние: GET, HEAD, OPTIONS, TRACE. Идемпотентные дают тот же результат при повторе: к безопасным добавляются PUT и DELETE. Не идемпотентны POST и, в общем случае, PATCH.
GET: чтение, тело запроса не предполагается, ответ кэшируется, параметры в строке запроса;POST: создание ресурса или операция, которая не ложится на CRUD; при успехе 201 и заголовокLocationс адресом созданного;PUT: полная замена ресурса по известному клиенту адресу, ответ 200 с телом или 204 без;PATCH: частичное изменение, формат тела описан отдельно: JSON Merge Patch (RFC 7386) или JSON Patch (RFC 6902), а не «пришлю те поля, что менял»;DELETE: удаление, обычно 204; на повторный вызов приемлемы и 404, и 204, главное чтобы это было зафиксировано в контракте;HEADиOPTIONS: заголовки без тела и запрос допустимых методов,OPTIONSвы видите в предварительных запросах CORS.
Про свой опыт говорите конкретно: какие ручки гоняли, чем (Postman, curl, автотесты на requests или REST Assured), какие коды проверяли на негативе (400, 401, 403, 404, 409, 422, 429), как тестировали повтор с заголовком Idempotency-Key на оплате.
Где спотыкаются
Считают PUT «методом для обновления одного поля». PUT заменяет ресурс целиком, и непереданные поля по контракту должны обнулиться.
Ставят знак равенства между REST и набором методов. REST это архитектурный стиль: ресурсы, единообразный интерфейс, отсутствие состояния сессии на сервере. Методы лишь его часть.
Проверяют только счастливый путь. Повторный запрос, гонка двух одновременных изменений и запрос к чужому идентификатору находят больше дефектов, чем весь позитивный набор.