Какие форматы данных можно отправить в HTTP

Форматы данных в HTTP-запросах

В HTTP-протоколе можно отправлять данные в самых разнообразных форматах, выбор которых зависит от типа запроса, ожиданий сервера и характера передаваемой информации. Как QA Engineer, я должен понимать эти форматы, чтобы правильно тестировать API, проверять валидацию данных, кодировки и обработку ошибок.

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

1. Form Data (application/x-www-form-urlencoded)

Стандартный формат для HTML-форм. Данные кодируются в виде пар "ключ=значение", объединенных амперсандом &. Символы кодируются в процентах (percent-encoding). Подходит для простых текстовых данных.

<!-- Пример HTML-формы -->
<form action="/submit" method="post">
  <input name="username" value="john">
  <input name="password" value="doe">
</form>

Тело запроса: username=john&password=doe

Тестирование: проверяем корректное кодирование спецсимволов (например, пробела как %20 или +), обработку пустых значений, лимиты на длину (для GET-запросов ограничение длины URL).

2. Multipart Form Data (multipart/form-data)

Используется для загрузки файлов вместе с текстовыми полями. Данные разбиваются на части (parts) с разделителями (boundary). Каждая часть содержит свои заголовки (например, Content-Type) и тело.

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123

------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="username"

john
------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

<бинарные данные файла>
------WebKitFormBoundaryABC123--

Тестирование: важно проверять обработку больших файлов (таймауты, лимиты размера), корректность MIME-типов, одновременную загрузку нескольких файлов, а также случаи с поврежденными или частично загруженными данными.

3. JSON (application/json)

Современный стандарт для RESTful API. Данные передаются в структурированном виде (объекты, массивы), что удобно для сложных данных. Поддерживается вложенность и разнообразные типы значений.

{
  "user": {
    "name": "John",
    "age": 30,
    "hobbies": ["reading", "hiking"]
  }
}

Тестирование: необходимо валидировать JSON-схему (типы полей, обязательность), обрабатывать некорректный JSON (синтаксические ошибки), а также проверять кодировки (особенно для Unicode-символов).

4. XML (application/xml, text/xml)

Используется в SOAP-сервисах и некоторых legacy-системах. Более многословен, чем JSON, но поддерживает сложные структуры, пространства имен и схемы (XSD).

<user>
  <name>John</name>
  <age>30</age>
</user>

Тестирование: проверяем корректность парсинга, валидацию по XSD-схеме, обработку XML-инъекций, экранирование спецсимволов (<, >).

5. Plain Text (text/plain)

Простой текст без структуры. Может использоваться для отправки логов, конфигураций или любых неформатированных данных.

Это просто текст, который нужно обработать.

Тестирование: проверяем кодировки (UTF-8, windows-1251), обработку переносов строк, больших объемов текста.

6. Binary Data

Прямая передача бинарных данных (например, изображений, PDF). Указывается соответствующий MIME-тип, например image/png, application/pdf.

Тестирование: важна проверка целостности данных после передачи, обработка поврежденных бинарных файлов, а также соответствие заявленного и фактического MIME-типа.

Другие форматы

• GraphQL: использует свой синтаксис, обычно передается как JSON, но с определенной структурой запросов.
• YAML: реже, но может использоваться в API, ориентированных на конфигурации.
• Protobuf (application/protobuf), MessagePack: бинарные форматы для повышения эффективности.

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

При тестировании API, работающих с разными форматами, я обращаю внимание на:

• Валидация данных: как сервер обрабатывает некорректные, неполные или malicious-данные (инъекции).
• Кодировки: поддержка UTF-8 для мультиязычных данных.
• Заголовки Content-Type: правильное указание и обработка (например, application/json vs text/json).
• Ограничения: размер тела запроса, timeout'ы при больших данных.
• Обработка ошибок: понятные сообщения об ошибках при несоответствии формата.
• Конвертация: возможность отправки данных в одном формате, а получения в другом (если API это поддерживает).

Понимание этих форматов позволяет QA Engineer не только составлять корректные тестовые запросы, но и проектировать тесты на граничные случаи, что критически важно для надежности и безопасности приложения.