В каком HTTP заголовке указывается тип и формат данных

Что проверяют

Знаете ли вы Content-Type и понимаете ли, что он бывает и в ответе, и в запросе. Для тестировщика важна практика: что делает сервер, если заголовок не совпадает с телом. Следом часто спрашивают, чем Content-Type отличается от Accept.

Как отвечать

Тип и формат данных указывает Content-Type. Значение это MIME-тип вида тип/подтип, иногда с параметрами: application/json или text/html; charset=utf-8. Самые частые:

• application/json: тела запросов и ответов REST API;
• application/x-www-form-urlencoded: обычная HTML-форма, пары ключ=значение;
• multipart/form-data: форма с файлами, параметр boundary задаёт разделитель частей;
• text/html, text/plain, application/xml: страницы, текст, XML;
• application/octet-stream: произвольные двоичные данные.

Рядом держите связанные заголовки:

• Accept: в запросе, какой формат клиент хочет получить. Если сервер не может его отдать, он вправе ответить 406 Not Acceptable или вернуть формат по умолчанию;
• Content-Encoding: сжатие тела, gzip или br. Это упаковка, а не формат;
• Content-Disposition: показать файл в браузере или скачать под заданным именем.

Что проверить в Postman или автотесте: POST с JSON-телом без Content-Type, с text/plain, с неверным charset. Правильная реакция на неподдерживаемый тип тела это 415 Unsupported Media Type, а не 500. В ответах проверяют, что API отдаёт JSON с application/json, а не с text/html, иначе клиент разберёт тело неверно.

Где спотыкаются

Путают Content-Type и Accept: первый описывает отправленное тело, второй просит формат ответа.

Не проверяют запросы с отсутствующим или неверным заголовком. Именно здесь всплывают 500 и стек-трейсы вместо аккуратного 415 или 400.

Вручную ставят multipart/form-data без boundary в Postman или в автотесте с FormData. Сервер не может разобрать тело, хотя инструмент сам проставил бы заголовок правильно, если его не трогать.