Какого формата body

Форматы тела HTTP-запросов и ответов (Body)

При работе с API в роли QA-инженера критически важно понимать форматы body HTTP-запросов (например, POST, PUT, PATCH) и ответов. Это основа для тестирования интеграций, валидации данных и поиска дефектов.

Основные форматы передачи данных

На практике наиболее распространены три формата:

1. JSON (JavaScript Object Notation) — абсолютный стандарт для современных RESTful и GraphQL API. Человекочитаемый, легковесный и легко обрабатывается большинством языков программирования.
2. XML (eXtensible Markupup Language) — чаще встречается в legacy-системах, SOAP-сервисах и некоторых специфичных областях (например, финансы). Более строгий и многословный, чем JSON.
3. Form Data (x-www-form-urlencoded и multipart/form-data) — используется в основном при отправке данных из HTML-форм. Первый — для простых пар "ключ-значение", второй — для загрузки файлов.

Для каждого из этих форматов в заголовке HTTP-запроса (Content-Type) указывается соответствующий MIME-тип:

• application/json
• application/xml или text/xml
• application/x-www-form-urlencoded
• multipart/form-data

Практическое значение для QA-инженера

Понимание форматов позволяет грамотно строить тесты и анализировать результаты:

• Позитивное и негативное тестирование: Нужно уметь формировать корректные тела запросов и намеренно искажать их (ломать структуру, менять типы данных, нарушать кодировки) для проверки устойчивости API.
• Валидация ответов: Ответ сервера также приходит в одном из этих форматов. Необходимо проверять не только HTTP-статус, но и соответствие структуры тела заявленной схеме (например, JSON Schema), типы данных, граничные значения и наличие обязательных полей.
• Инструментарий: Умение работать с этими форматами — ключевой навык при использовании Postman, SoapUI, ReadyAPI или при написании автотестов на Python (с requests), JavaScript или Java.

Примеры для наглядности

1. JSON (наиболее частый в моей практике):

{
  "user": {
    "id": 12345,
    "name": "Алексей Петров",
    "email": "alexey.p@example.com",
    "isActive": true,
    "roles": ["viewer", "editor"]
  }
}

В заголовке: Content-Type: application/json.

2. XML (встречается реже, но требует внимания):

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>12345</id>
  <name>Алексей Петров</name>
  <email>alexey.p@example.com</email>
  <isActive>true</isActive>
  <roles>
    <role>viewer</role>
    <role>editor</role>
  </roles>
</user>

В заголовке: Content-Type: application/xml.

3. Form Data (x-www-form-urlencoded):

name=Алексей+Петров&email=alexey.p%40example.com&isActive=true

В заголовке: Content-Type: application/x-www-form-urlencoded.

4. Form Data (multipart/form-data для загрузки файла): Используется специальная граница (boundary). В Postman это формируется автоматически при выборе типа form-data и добавлении файла.

--boundary-example
Content-Disposition: form-data; name="document"; filename="report.pdf"
Content-Type: application/pdf

<содержимое бинарного файла>
--boundary-example--

Ключевые аспекты для тестирования

• Синтаксическая корректность: Передаваемый JSON/XML должен быть валидным. Невалидный (например, с лишней запятой в JSON) должен обрабатываться с ошибкой 4xx (чаще 400 Bad Request).
• Соответствие контракту (схеме): Тело запроса должно строго соответствовать ожидаемой API схеме (Swagger/OpenAPI, WSDL). Пропуск обязательного поля или неверный тип данных — повод для ошибки валидации (например, 422 Unprocessable Entity).
• Кодировка и экранирование символов: Особенно важно для текстов на кириллице или специальных символах (&, <, >). В JSON обычно используется UTF-8, в x-www-form-urlencoded — процентное кодирование.
• Размер тела: API часто имеют лимиты на размер принимаемого body. Попытка отправить слишком большой JSON или файл должна приводить к ошибке (например, 413 Payload Too Large).

Таким образом, для QA-инженера вопрос "какого формата body" — это отправная точка для проектирования целого спектра проверок: от базовой функциональности до безопасности и производительности API. Умение работать с этими форматами вручную и через автоматизацию — обязательный профессиональный навык.