В каком формате можно передать данные в POST-запросе

Основные форматы данных в POST-запросе

При отправке POST-запроса клиент (браузер, мобильное приложение, скрипт) может передавать данные на сервер в различных форматах. Выбор формата зависит от типа контента (Content-Type), указанного в заголовках запроса, и от того, как серверное приложение ожидает получать информацию.

1. application/x-www-form-urlencoded (стандартная HTML-форма)

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

Пример тела запроса:

POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 31

name=John+Doe&age=30&city=New+York

2. multipart/form-data

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

Пример тела запроса:

POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 342

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="name"

John Doe
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

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

3. application/json

Современный и широко используемый формат для RESTful API. Данные передаются в виде строки в формате JSON (JavaScript Object Notation), что позволяет передавать сложные структуры: объекты, массивы, вложенные данные.

Пример тела запроса:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 56

{
    "name": "John Doe",
    "age": 30,
    "city": "New York"
}

4. text/plain и text/xml

• text/plain – данные передаются в виде обычного текста без какого-либо специального форматирования. Используется редко, в основном для отладки.
• text/xml или application/xml – данные передаются в формате XML. Ранее был популярен для SOAP API, сейчас встречается реже, чем JSON.

Пример тела запроса в XML:

POST /api/data HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 110

<user>
    <name>John Doe</name>
    <age>30</age>
    <city>New York</city>
</user>

5. application/octet-stream

Используется для передачи сырых бинарных данных (например, содержимого файла без метаинформации). Сервер интерпретирует весь поток тела запроса как один файл.

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

Также могут использоваться специализированные форматы, такие как application/graphql для запросов GraphQL или кастомные форматы, определенные конкретным API (например, application/vnd.api+json для JSON:API).

С точки зрения QA Engineer: на что обращать внимание

При тестировании API, отправляющего POST-запросы, важно проверять:

• Корректность заголовка Content-Type – он должен соответствовать фактически отправляемому телу запроса.
• Обработку сервером различных форматов – что происходит, если отправить JSON вместо form-data или наоборот? Сервер должен возвращать адекватную ошибку (например, 415 Unsupported Media Type).
• Валидацию данных – как сервер обрабатывает некорректный, неполный или поврежденный контент (битый JSON, неверная граница в multipart, незакодированные спецсимволы).
• Ограничения по размеру – особенно актуально для multipart/form-data при загрузке больших файлов.
• Кодировку символов – для текстовых данных.

Пример теста на негативный сценарий с помощью cURL:

# Отправка JSON с указанием неверного Content-Type
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d '{"name":"John"}'  # Тело в формате JSON, а заголовок - form-urlencoded

Ожидаемое поведение: сервер должен вернуть ошибку 4xx (например, 400 Bad Request или 415 Unsupported Media Type), а не обработать запрос некорректно или упасть.

Выбор формата определяется:

1. Требованиями API (документацией, спецификацией OpenAPI/Swagger).
2. Характером данных: простые формы → x-www-form-urlencoded, файлы → multipart/form-data, сложные структуры → application/json.
3. Экосистемой и стандартами: современные веб-сервисы и микросервисы предпочитают JSON.