Перейти на PRO

Из чего состоит API-запрос?

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

Ответ

API-запрос, особенно в контексте HTTP/HTTPS, состоит из следующих ключевых компонентов:

  1. Метод (HTTP Method): Определяет тип операции над ресурсом.

    • GET — получение данных.
    • POST — создание нового ресурса.
    • PUT — полное обновление ресурса.
    • PATCH — частичное обновление ресурса.
    • DELETE — удаление ресурса.

  2. URL (Endpoint/Uniform Resource Locator): Адрес целевого ресурса на сервере. Может включать путь и параметры.

  3. Заголовки (Headers): Метаданные запроса, описывающие клиент, формат данных, требования к кэшированию и аутентификацию.

    • Content-Type (например, application/json) — указывает формат тела запроса.
    • Authorization (например, Bearer <token>) — содержит учетные данные.
    • Accept — сообщает серверу, какой формат ответа предпочтителен.

  4. Параметры запроса (Query Parameters): Пары «ключ=значение», добавляемые в URL после ? для фильтрации, сортировки или пагинации (например, ?page=2&limit=10).

  5. Тело запроса (Request Body): Данные, отправляемые на сервер, обычно в методах POST, PUT, PATCH. Распространенные форматы:

    • JSON ({"name": "John"})
    • XML
    • Form-data
    • Plain text

Пример для тестировщика: При тестировании API я проверяю каждый компонент. Например, для негативного теста можно отправить POST-запрос с неверным Content-Type (например, text/plain вместо application/json) и убедиться, что сервер возвращает корректную ошибку 415 Unsupported Media Type.

# Пример валидного POST-запроса для создания пользователя
POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
    "email": "user@example.com",
    "name": "Alice"
}

Ответ 18+ 🔞

Давай разберём эту всю API-хуйню, как будто я тебе на кухне объясняю, пока чайник кипит. Представь, что ты хочешь не просто сайт открыть, а постучаться к серверу и сказать: «Эй, мужик, дай-ка мне инфу» или «Слушай, запиши вот это». Вот этот стук в дверь к серверу — это и есть API-запрос. А состоит он из нескольких важных кусков, без которых нихуя не получится.

Первое — Метод (HTTP Method). Это как глагол, действие. Ты что хочешь сделать?

  • GET — это как «дай посмотреть». Получить данные. Без изменений, просто дай.
  • POST — «создай новое». Отправляешь данные, чтобы на сервере появилась новая запись, пользователь, заказ — что угодно.
  • PUT — «перепиши всё полностью». Говоришь: «Вот новые данные, замени старые на эти, и точка».
  • PATCH — «подправь чутка». Не всё переписывать, а только одно поле поменять, например.
  • DELETE — ну тут всё ясно, «удали нахуй этот ресурс».

Второе — URL (или Endpoint). Это просто адрес. Куда стучишься. Как https://api.магазин.com/products. Может быть с путями типа /api/v1/users/123, а может ещё и с параметрами запроса (Query Parameters) — это когда после знака вопроса ? идёт page=2&limit=10. Типа «дай мне вторую страницу, по 10 штук на странице». Удобно, ёпта.

Третье — Заголовки (Headers). Это такая служебная информация, метаданные. Без неё сервер может нихуя не понять. Самые важные:

  • Content-Type — говоришь серверу, в каком формате ты ему данные суёшь. application/json — это классика, структурированный JSON. Если отправишь text/plain, а он ждёт JSON — получишь ошибку, и правильно.
  • Authorization — тут ты предъявляешь пропуск. Чаще всего это Bearer <тут_твой_токен>. Без него — пошёл нахуй, доступ закрыт.
  • Accept — а это ты наоборот, серверу говоришь: «А отвечать-то мне, пожалуйста, в таком-то формате». Вдруг он XML любит, а ты JSON хочешь.

Четвёртое — Тело запроса (Request Body). Это сами данные, которые ты передаёшь. Работает в основном для POST, PUT, PATCH. Кидаешь туда, например, JSON-объект, как в примере ниже. Главное — заголовок Content-Type должен соответствовать, а то сервер обоссуется и вернёт тебе 415 Unsupported Media Type. Проверено.

Как тестировщику на это смотреть? Да элементарно! Берёшь и ломаешь. Это же наша работа. Вот смотри: нужно протестировать создание пользователя (POST /users). Делаешь валидный запрос — всё ок. А потом начинаешь ёбать колотить систему. Отправляешь тот же запрос, но в заголовке Content-Type ставишь text/plain вместо application/json. И смотришь — отдаёт ли сервер адекватную ошибку 415. Если отдаёт — молодец. Если падает в тартарары или создаёт пользователя с битыми данными — пидарас шерстяной, разработчикам баг в трекер.

Вот, смотри, как красивый, правильный запрос выглядит:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

{
    "email": "user@example.com",
    "name": "Alice"
}

Всё по полочкам: метод POST, адрес /api/v1/users, в заголовках сказали, что тело в JSON и токен приложили, а в самом теле — данные новой юзерши. Если всё правильно — сервер ответит что-то вроде 201 Created, и Alice будет в базе. Если где-то накосячишь — получишь по шапке с кодом ошибки. Вот и вся магия, никакого хуя с горы.

© ХакСобесов, 2026
support@hacksobesov.com