Где можно передавать параметры в HTTP-запросе?

Question

Где можно передавать параметры в HTTP-запросе?

Тип вопроса: API тестирование Вероятность: 24% Категория: AQA / Automation

Ответ

При тестировании API параметры можно передавать в четырех основных местах HTTP-запроса:

Query Parameters (Параметры строки запроса)
- Место: Добавляются в URL после знака ? в формате ключ=значение, разделяются &.
- Назначение: Используются для фильтрации, сортировки, пагинации, обычно в GET-запросах.
- Пример URL: GET /api/users?role=admin&active=true
Path Parameters (Параметры пути)
- Место: Являются частью самого пути URL, часто обозначаются фигурными скобками в спецификации.
- Назначение: Используются для идентификации конкретного ресурса.
- Пример URL: GET /api/users/{userId}/orders → GET /api/users/123/orders
Request Body (Тело запроса)
- Место: Отдельная часть запроса, не видимая в URL.
- Назначение: Для передачи сложных данных при создании (POST) или обновлении (PUT, PATCH) ресурсов.
- Форматы: JSON (наиболее распространен), XML, x-www-form-urlencoded.
- Пример (JSON):
```
{
"name": "John Doe",
"email": "john@example.com"
}
```
Headers (Заголовки)
- Место: Метаданные HTTP-запроса.
- Назначение: Передача служебной информации: авторизация (Authorization: Bearer <token>), тип контента (Content-Type: application/json), управление кэшем.

С точки зрения тестировщика важно:

Проверять валидацию параметров во всех этих местах (корректные, некорректные, граничные значения).
Понимать, какой метод (GET, POST и т.д.) с каким местом передачи параметров используется в тестируемом API.
Использовать инструменты вроде Postman или код для отправки таких запросов.

Ответ 18+ 🔞

Бля, ну смотри, тут про передачу параметров в API. Всё просто, как три копейки, но если не знать — можно охуеть с того, куда их пихать. Их, сука, можно засунуть аж в четыре разных места, и у каждого своя фишка. Разберём по полочкам, а то потом будешь как мартышка с гранатой — непонятно, что и куда.

Первое и самое видное место — Query Parameters, или, по-нашему, параметры строки запроса. Это когда в URL, после основного адреса, идёт знак вопроса, а потом какая-то хуйня вроде ключ=значение. Если параметров несколько, их разделяют амперсандом &. Используется это обычно в GET-запросах для всякой фильтрации, сортировки или пагинации. Например, хочешь получить только админов: GET /api/users?role=admin&active=true. Всё на виду, всё прозрачно. Но если наделаешь там овердохуища параметров — URL превратится в пиздопроебибну строку, которую и прочитать-то страшно.

Дальше идут Path Parameters, или параметры пути. Это уже часть самого пути URL. Часто в документации они обозначены фигурными скобками. Нужны, чтобы указать на конкретный ресурс, типа «дай мне пользователя с ID 123». Выглядит это так: в спецификации GET /api/users/{userId}/orders, а на деле шлёшь GET /api/users/123/orders. Удобно, наглядно, и сразу понятно, к чему обращаемся. Если тут накосячить и передать вместо числа строку — сервер тебе такую ошибку вывалит, что мало не покажется.

Третье место — святое святых для сложных данных, Request Body, или тело запроса. Это отдельная часть запроса, её в URL не видно. Туда обычно засовывают целые JSON-объекты, когда нужно что-то создать (POST) или обновить (PUT, PATCH). Форматов бывает несколько, но все давно договорились, что JSON — наш царь и бог. Выглядит это примерно так:

{
  "name": "John Doe",
  "email": "john@example.com"
}

Главное — не забыть в заголовках указать Content-Type: application/json, а то сервер может не понять, что ты ему эту кашу в рот пихаешь, и отправит тебя нахуй с ошибкой 415.

Ну и наконец, четвёртое — Headers, или заголовки. Это такая служебная информация, которая летит впереди основного запроса. Там всякая важная хуйня: токены для авторизации (Authorization: Bearer <token>), тип передаваемого контента, настройки кэша и прочая лабуда. Без правильных заголовков даже самый красивый запрос может накрыться медным тазом.

С точки зрения тестировщика тут главное — не бздеть и проверять всё подряд. Надо валидировать параметры во всех этих четырёх местах: и корректные значения гонять, и некорректные, и граничные — чтобы посмотреть, где система начнёт блевать. Важно чётко понимать, какой HTTP-метод с каким местом передачи используется. Ну и, конечно, без инструментов никуда — Postman там, или код свой писать, чтобы эти запросы швырять. А то руками это, ёпта, как в каменном веке.