Ответ
При тестировании API тело запроса (payload) может быть представлено в различных форматах. Ключевой заголовок Content-Type указывает серверу, как интерпретировать данные.
Основные форматы тела запроса:
Формат (Content-Type) |
Описание | Пример тела |
|---|---|---|
application/json |
Наиболее популярен для REST API. Структурированный, удобочитаемый. | {"user": "alice", "active": true} |
application/x-www-form-urlencoded |
Пары "ключ=значение", разделенные &. Кодирует пробелы как + или %20. |
name=John+Doe&city=New+York |
multipart/form-data |
Для отправки файлов и смешанных данных. Каждая часть имеет свои заголовки. | (см. пример в ответе на вопрос 691) |
application/xml / text/xml |
Структурированные данные в формате XML. | <request><user>alice</user></request> |
text/plain |
Простой неформатированный текст. | This is a plain text payload. |
Бинарные данные (например, image/png) |
Непосредственная передача файла (изображения, PDF и т.д.). | [байты файла] |
Почему это важно для тестировщика:
- Валидация: Сервер может отвергать запросы с неправильным
Content-Type. - Обработка ошибок: Нужно проверять, как API реагирует на неожиданные форматы (например, отправить XML в endpoint, ожидающий JSON).
- Инструменты: В Postman, Insomnia или скриптах (
requests,curl) необходимо корректно задавать и заголовок, и тело.
Пример curl для отправки JSON:
curl -X POST https://api.example.com/items
-H "Content-Type: application/json"
-d '{"title": "Test Item"}'Ответ 18+ 🔞
А, слушай, смотри, вот эта вся хуйня с форматами тела запроса — это ж основа основ, блядь! Как придёшь на сервер, так сразу тебе: "А ты кто такой? В каком виде пришёл?" И если ты не в том виде, тебя нахуй вышвырнут, даже слушать не станут.
Вот эти все твои варианты, как можно прийти:
Формат (Content-Type) |
Что это за зверь | Пример, как выглядит внутри |
|---|---|---|
application/json |
Царь и бог, ёпта. Все его любят, все с ним работают. Красиво, структурированно, читабельно. | {"user": "alice", "active": true} |
application/x-www-form-urlencoded |
Старый дедок из веба. Всё клеит через &, пробелы превращает в плюсики. Простой, как три копейки. |
name=John+Doe&city=New+York |
multipart/form-data |
Мультитул, блядь! Когда надо и файл притащить, и текст передать. Там внутри целый цирк с границами и заголовками. | (ну там, в другом вопросе смотри, там дохуя всего) |
application/xml / text/xml |
Любитель сложностей. Всё в тегах, всё должно быть валидным, а то сейчас в рот тебе чих-пых с ошибкой парсинга! | <request><user>alice</user></request> |
text/plain |
Просто текст, без затей. "Мама мыла раму" и всё. Никаких тебе структур. | This is a plain text payload. |
Бинарные данные (типа image/png) |
А это когда ты прямо файлом в ебальник серверу лепишь. Байты, блядь, просто поток байтов. | [байты файла] |
А теперь, зачем тебе, как тестировщику, эта вся хуета в голове крутиться?
- Валидация, ёб твою мать! Отправишь JSON, а в заголовке напишешь
text/plain— сервер тебя пошлёт нахуй с ошибкой415 Unsupported Media Typeили ещё какой пиздец в ответ пришлёт. Надо проверять, что он действительно требует то, что говорит. - Обработка ошибок — это святое! А что будет, если эндпоинт, который ждёт JSON, получит XML? Он сдохнет красиво или начнёт блевать непонятными ошибками? Это же надо проверять, блядь! Это и есть твоя работа — доводить систему до белого каления.
- Инструменты, сука! В том же Postman или когда скрипты на
requestsпишешь — не забудь этот ебучийContent-Typeзаголовок выставить, а то отправишь одно, а сервер будет ждать другое. Пиздец и недопонимание.
Вот, смотри, как это по-простому через curl делается, чтобы JSON отправить:
curl -X POST https://api.example.com/items
-H "Content-Type: application/json"
-d '{"title": "Test Item"}'Видишь? -H — это заголовок, говорим: "Братан, я к тебе с JSON'ом пришёл". А -d — это само тело, данные. Всё просто, как два пальца обоссать. Главное — не перепутай, а то вместо уважения получишь в жопу пинка от API.