Какие форматы данных можно использовать в теле POST-запроса?

Question

Какие форматы данных можно использовать в теле POST-запроса?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Тело POST-запроса может передавать данные в различных форматах, указанных в заголовке Content-Type. Основные форматы:

application/x-www-form-urlencoded Стандартный формат для HTML-форм. Данные кодируются в виде пар ключ=значение, объединенных амперсандом &. Символы пробела заменяются на +.
```
POST /submit HTTP/1.1
Content-Type: application/x-www-form-urlencoded

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

multipart/form-data Используется для загрузки файлов. Каждая часть данных (поля формы или файлы) разделяется уникальной границей (boundary).

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123

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

Profile picture
----WebKitFormBoundaryABC123
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

[бинарные данные файла]
----WebKitFormBoundaryABC123--

application/json Наиболее популярный формат для REST API. Данные передаются в структурированном JSON-виде.
```
POST /api/users HTTP/1.1
Content-Type: application/json

{
  "name": "John Doe",
  "age": 30,
  "city": "New York"
}
```
text/xml или application/xml Используется в SOAP API и некоторых legacy-системах.
```
POST /soap/service HTTP/1.1
Content-Type: text/xml

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

Выбор формата зависит от требований API: multipart/form-data — для файлов, application/json — для структурированных данных в современных API, x-www-form-urlencoded — для простых форм.

Ответ 18+ 🔞

Так, слушай, смотри, это же ж простая хуйня, но её постоянно путают, блядь! Тело запроса — это как посылка, а Content-Type — это наклейка, на которой написано, что внутри и как распаковать. Если наклейку ебнуть, сервер тебя просто не поймёт, будет сидеть и думать: «Чё это за хуйню мне прислали?».

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

application/x-www-form-urlencoded Это как старый добрый советский чемодан. Всё упаковано по полочкам, но тесно. Данные превращаются в вот такую строчку: ключ=значение&ключ2=значение2. Пробелы, блядь, заменяются на плюсики. Это стандарт для обычных HTML-форм, которые не файлы шлют.
```
POST /submit HTTP/1.1
Content-Type: application/x-www-form-urlencoded

name=John+Doe&age=30&city=New+York
```
Видишь? Всё просто, как три копейки. name — это Джон, age — тридцать, city — Нью-Йорк. Сервер разберёт.
multipart/form-data А вот это уже, сука, коробка с перегородками! Используется, когда нужно отправить не только текст, но и файлы — картинки, документы, хуйню всякую. Тут данные делятся на части (part), и каждая часть отделена уникальной границей (boundary). Выглядит страшновато, но логика проще пареной репы.
```
POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123

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

Profile picture
----WebKitFormBoundaryABC123
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

[бинарные данные файла]
----WebKitFormBoundaryABC123--
```
Смотри: одна часть — это поле description с текстом «Profile picture». Другая часть — это сам файл photo.jpg с его бинарным содержимым. Всё аккуратно, ничего не перемешалось. Без этого формата загрузить файл через форму — нихуя не получится.
application/json Это, блядь, король современных API! Всё структурированно, красиво, машиночитаемо. Данные в виде JSON-объекта. Если ты пишешь REST API и не используешь JSON — ты, прости, мудак.
```
POST /api/users HTTP/1.1
Content-Type: application/json

{
  "name": "John Doe",
  "age": 30,
  "city": "New York"
}
```
Чисто, понятно, элегантно. Серверу легко распарсить, тебе легко сформировать. Любой уважающий себя бэкендер ждёт от тебя именно этого.
text/xml или application/xml Ну, это, блядь, наследие прошлого, как ламповый телевизор. Используется в этих ваших SOAP API и прочем старье. Выглядит раздуто и многословно.
```
POST /soap/service HTTP/1.1
Content-Type: text/xml

<user>
  <name>John Doe</name>
  <age>30</age>
</user>
```
Тот же смысл, но обёрнут в тонну тегов. Если работаешь с каким-нибудь древним банковским или государственным сервисом — готовься к этому пиздецу.

Итог, ёпта: Выбор формата — это не твоя прихоть, а требование того сервера, в который ты стучишься.

Файлы шлёшь? — multipart/form-data, иначе нихуя.
Современное API дербанишь? — application/json, без вариантов.
Простую HTML-форму эмулируешь? — x-www-form-urlencoded.
Попал в 2005-й год? — text/xml, и да пребудет с тобой сила.

Главное — не перепутай наклейки, а то вместо Джона Доу серверу прилетит какая-то нечитаемая хуйня, и он тебе в ответ такую ошибку вывалит, что мало не покажется.