Какие поля заполняются при отправке REST запроса

Что проверяют

Понимаете ли вы, из чего состоит HTTP-запрос и что из этого тестировщик меняет руками при проверке API. Следом почти всегда просят показать запрос в Postman или curl и спрашивают, чем параметры пути отличаются от параметров строки запроса.

Как отвечать

Разложите запрос на части:

• метод: GET читает, POST создаёт, PUT заменяет ресурс целиком, PATCH меняет часть полей, DELETE удаляет. GET и DELETE обычно идут без тела;
• URL: схема, хост, путь с параметрами пути (/users/42) и строка запроса (?status=active&page=2). Параметры пути адресуют ресурс, query фильтрует и листает;
• заголовки: Content-Type (формат тела, чаще application/json), Accept (какой формат ответа ждём), Authorization (Bearer <токен> или Basic), иногда Cookie, Idempotency-Key, заголовок трассировки вроде X-Request-Id. Host и Content-Length клиент ставит сам;
• тело: JSON, multipart/form-data для файлов или application/x-www-form-urlencoded для форм.

Дальше покажите, как это превращается в тесты. Контракт берётся из спецификации OpenAPI (Swagger): какие поля обязательны, какие у них типы и ограничения. Проверки строятся вокруг каждой части запроса: без Authorization ждём 401, с токеном без нужных прав 403, без обязательного поля или с неверным типом 400 или 422, с несуществующим id в пути 404, повторный POST с тем же Idempotency-Key не создаёт дубль. В Postman запросы собирают в коллекцию с переменными окружения, а в автотестах повторяют через REST Assured, requests с pytest или аналог в своём стеке.

Где спотыкаются

Относят коды состояния к полям запроса. Код приходит в ответе, в самом запросе его нет.

Путают PUT и PATCH и не проверяют, что сервис делает с пропущенными полями. По семантике PUT это полная замена, и молча сохранённое старое значение часто оказывается багом или хотя бы расхождением с документацией.

Считают, что Content-Type нужен всегда. Он описывает тело, и у GET без тела не обязателен, а вот неверный Content-Type у POST сервер обычно отвергает с 415.