HTTP заголовки

Content-Type заголовок: Основные типы контента в HTTP

📚 30 вопросовПройти тест →
Лекция

Content-Type заголовок: Основные типы контента в HTTP

HTTP заголовки

Content-Type заголовок: Основные типы контента в HTTP

Введение: наклейка на посылке 📦

Если вы отправляете посылку, на ней должна быть наклейка «стекло», «еда», «документы».
Content‑Type — это такая же наклейка для данных в HTTP.
💡 Совет: без Content‑Type клиент не поймёт, как «читать» тело.
✅ Вывод: Content‑Type — ключ к пониманию данных.

Проблема → решение

Проблема: если не указывать Content‑Type, сервер и клиент могут трактовать данные по‑разному.
Решение: всегда задавать Content‑Type и проверять его на сервере.
✅ Вывод: заголовок Content‑Type делает обмен предсказуемым.

Чем помогает и как работает

Content‑Type нужен, чтобы сервер и клиент понимали формат данных. Без него данные могут быть прочитаны неправильно.
Как это работает:
  1. Клиент отправляет тело и указывает Content-Type.
  2. Сервер парсит данные по этому формату.
  3. В ответе сервер возвращает свой Content‑Type.
✅ Вывод: корректный Content‑Type = корректная обработка данных.

Ключевые термины (простыми словами)

  • Content‑Type — тип данных в запросе/ответе.
  • MIME‑type — формат: application/json, text/html.
  • Accept — какие форматы клиент ожидает.
  • Boundary — границы частей в multipart.
  • Charset — кодировка текста (UTF‑8).
✅ Вывод: тип контента — язык между клиентом и сервером.

Самое важное (must‑know)

  • JSON = application/json.
  • Файлы = multipart/form-data.
  • Неверный Content‑Type > 415 Unsupported Media Type.
  • Ответ всегда должен иметь Content‑Type.
  • Accept помогает выбрать формат ответа.
✅ Вывод: без этих правил данные ломаются.

1. application/json

Назначение: передавать структурированные данные.
Простыми словами: самый популярный формат для API.
Аналогия: анкета в виде таблицы.
Пример:
Content-Type: application/json
🔎 Как это происходит на практике:
  1. Клиент отправляет JSON‑тело в POST /courses.
  2. Ставит Content-Type: application/json.
  3. Сервер парсит JSON и возвращает ответ в том же формате.
Характеристики:
  • ✅ читаемость;
  • ✅ стандарт для REST;
  • ✅ поддерживается везде.
Когда использовать: почти всегда в API.
✅ Вывод: JSON — базовый формат API.

2. multipart/form-data

Назначение: отправлять файлы и поля формы.
Простыми словами: упаковка нескольких частей.
Аналогия: посылка с несколькими предметами.
Пример:
Content-Type: multipart/form-data; boundary=----XYZ
🔎 Как это происходит на практике:
  1. Клиент загружает файл + поля формы.
  2. Браузер формирует multipart/form-data с boundary.
  3. Сервер читает части и сохраняет файл.
Характеристики:
  • ✅ подходит для файлов;
  • ✅ умеет содержать текст и бинарные части;
  • ✅ больше размер.
Когда использовать: загрузка файлов, аватары.
✅ Вывод: multipart = стандарт для upload.

3. application/x-www-form-urlencoded

Назначение: классические формы.
Простыми словами: данные как в URL, но в теле.
Аналогия: бумажная анкета.
Пример:
name=Ivan&age=30
🔎 Как это происходит на практике:
  1. Старый HTML‑формат отправляет name=Ivan&age=30.
  2. Content-Type — application/x-www-form-urlencoded.
  3. Сервер парсит пары ключ=значение.
Характеристики:
  • ✅ простая форма;
  • ✅ устаревший вариант;
  • ✅ подходит для небольших данных.
Когда использовать: старые формы/совместимость.
✅ Вывод: используется, но уступает JSON.

4. text/plain и text/html

Назначение: передавать текст.
Простыми словами: обычная строка.
Аналогия: письмо без форматирования.
Пример:
Content-Type: text/plain; charset=UTF-8
🔎 Как это происходит на практике:
  1. Сервис возвращает простое текстовое сообщение.
  2. Ставит Content-Type: text/plain; charset=UTF-8.
  3. Для страницы HTML используется text/html.
Характеристики:
  • ✅ лёгкий формат;
  • ✅ удобен для логов;
  • ✅ не для структурных данных.
Когда использовать: простые тексты, статусы.
✅ Вывод: text/plain — для простых сообщений.

5. Accept и согласование форматов

Назначение: выбрать формат ответа.
Простыми словами: клиент говорит, что хочет получить.
Аналогия: «мне нужна книга в PDF, а не бумажная».
Пример:
Accept: application/json
🔎 Как это происходит на практике:
  1. Клиент отправляет Accept: application/json.
  2. Сервер выбирает JSON как формат ответа.
  3. Если Accept не задан — отдаёт формат по умолчанию.
Характеристики:
  • ✅ помогает серверу выбрать формат;
  • ✅ важно для API‑версий;
  • ✅ без Accept сервер выбирает дефолт.
Когда использовать: когда поддерживается несколько форматов.
✅ Вывод: Accept = запрос формата.

Сравнение типов контента

ТипКогдаПример
application/jsonAPI‑данные{"id":1}
multipart/form-dataфайлыupload
x-www-form-urlencodedформыname=Ivan
text/plainпростые строкиOK
✅ Вывод: разные форматы — разные задачи.

Часто спрашивают на собеседованиях

  • Что такое Content‑Type‑ тип данных в запросе/ответе.
  • Когда 415? если формат не поддерживается.
  • Чем JSON отличается от form‑data‑ JSON — структура, form‑data — файлы/формы.
  • Зачем Accept? выбрать формат ответа.
  • Нужен ли charset? да, для текста.
✅ Вывод: Content‑Type — обязательный базовый вопрос.

Типичные ошибки

Ошибка 1: нет Content‑Type

❌ тело есть, заголовка нет
✅ Content‑Type указан
Почему: иначе сервер не распарсит.

Ошибка 2: JSON как text/plain

❌ Content-Type: text/plain
✅ Content-Type: application/json
Почему: формат не совпадает.

Ошибка 3: file upload без multipart

❌ отправка файла как JSON
✅ multipart/form-data
Почему: бинарные данные должны быть в multipart.

Ошибка 4: Accept игнорируется

❌ сервер всегда JSON
✅ учитывает Accept
Почему: клиент может хотеть другой формат.

Best Practices

  • Всегда указывайте Content‑Type.
  • Проверяйте формат на сервере.
  • Возвращайте 415 при неподдерживаемом типе.
  • Используйте Accept, если есть несколько форматов.
  • Для файлов — multipart/form-data.

Заключение

📦 Content‑Type объясняет, что внутри запроса.
✅ Он спасает от ошибок парсинга.
🚀 Теперь вы умеете правильно подписывать данные в API.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Content-Type заголовок: Основные типы контента в HTTP»

Пройти тест →