Ответ сервера устроен почти как запрос — та же текстовая форма с заголовками и телом. Разница только в первой строке: вместо метода и пути сервер пишет, чем закончилась обработка.

HTTP/1.1 201 Created
Date: Mon, 12 May 2026 14:28:02 GMT
Content-Type: application/json
Content-Length: 89
Location: /api/posts/123
Cache-Control: no-store

{"id": 123, "title": "Привет, мир", "body": "Это мой первый пост.", "author": "anna"}

Разберём по частям.

Статусная строка: версия + код + текст

Первая строка ответа:

HTTP/1.1 201 Created

  • Версия протокола — такая же, как у запроса.
  • Числовой статус — 201. Главная единица информации в ответе: что произошло.
  • Текстовое описание — Created. Человеко-читаемая подсказка, что значит код. Для людей. Программы смотрят на число, не на текст.

Статус-коды разбиты на пять семейств: 1xx (информационные, редко встречаются), 2xx (успех), 3xx (перенаправления), 4xx (ошибка клиента), 5xx (ошибка сервера). Подробный разбор — в главе 3.3.

Заголовки ответа

Так же, как у запроса, — пары Имя: значение. Только теперь это метаданные о том, что прислал сервер:

  • Content-Type — формат тела ответа. Для REST это обычно application/json; charset=utf-8.
  • Content-Length — размер тела в байтах.
  • Date — время, когда сервер сформировал ответ.
  • Cache-Control — правила кэширования ответа браузером и прокси. Подробно — в главе 5.5.
  • ETag — «отпечаток» ответа для условных запросов. Тоже в главе 5.5.
  • Location — адрес созданного ресурса. Появляется в ответах с кодом 201 (Created) и 3xx (редирект).
  • Set-Cookie — куки, которые сервер просит браузер сохранить.
  • Заголовки с префиксом Access-Control- — настройки CORS. Подробно — в модуле 8.

Пустая строка и тело

После заголовков — та же обязательная пустая строка-разделитель, потом тело:

{"id": 123, "title": "Привет, мир", "body": "Это мой первый пост.", "author": "anna"}

Тело может быть JSON, HTML, картинкой, текстом, бинарным потоком — что угодно. В REST API почти всегда JSON, но если запрос ушёл с ошибкой, в теле может прилететь HTML-страница со стандартной ошибкой сервера. На это надо быть готовым (об этом в модуле 6).

Ответ может быть без тела

У некоторых статусов тело не должно приходить:

  • 204 No Content — запрос успешен, но возвращать нечего. Типичный ответ на удачный DELETE.
  • 304 Not Modified — данные не изменились с прошлого раза, бери из кэша. Про этот код — в главе 5.5.

В fetch попытка позвать response.json() на ответе с пустым телом упадёт с ошибкой парсинга — типичная ловушка для новичка. Лечится проверкой статуса перед чтением тела.

Что читать в первую очередь

Когда ответ приходит, фронтенду в 95% случаев интересны три вещи в таком порядке:

  1. Статус-код. Понять, успех или ошибка.
  2. Тело. Если успех — забрать данные. Если ошибка — забрать сообщение об ошибке.
  3. Заголовки. Иногда нужны — Location у созданного ресурса, Content-Type для выбора способа парсинга, X-RateLimit-Remaining у API с лимитами. Но обычно — нет.

Дальше — знакомство с JSON, потому что почти всё, что мы будем парсить в этом курсе, придёт именно в нём.