Какова структура HTTP-ответа

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

Понимаете ли вы ответ сервера настолько, чтобы описать его в спецификации API и разобрать в DevTools или Postman. Следом почти всегда спрашивают про коды: чем 401 отличается от 403 и что вернуть при ошибке валидации.

Как отвечать

В HTTP/1.1 ответ это текст из четырёх частей:

• строка состояния: версия протокола, код и поясняющая фраза, например HTTP/1.1 201 Created. Клиент ориентируется на код, фраза ни на что не влияет;
• заголовки: пары Имя: значение. Content-Type говорит, как читать тело, Content-Length задаёт его размер, Cache-Control и ETag управляют кэшем, Location указывает на созданный ресурс при 201 или адрес перехода при 3xx, Set-Cookie ставит куку, Retry-After подсказывает, когда повторить после 429 или 503;
• пустая строка: граница между заголовками и телом;
• тело: JSON, HTML, файл. Его может не быть: у 204 и 304 тела нет, у ответа на HEAD тоже.

Коды делятся на классы: 1xx информационные, 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера.

Аналитику важно показать, как это ложится в документацию. В OpenAPI у каждой операции описаны ответы по кодам со схемой тела, а ошибки удобно привести к единому формату, например Problem Details по RFC 9457 с типом application/problem+json. Плюсом будет заметить, что в HTTP/2 и HTTP/3 ответ идёт бинарными фреймами, код передаётся псевдозаголовком :status, поясняющей фразы нет, но логическая структура та же.

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

Путают 401 и 403. 401 значит «вы не аутентифицированы», 403 значит «вы известны, но прав нет».

Проектируют API, где на любую ошибку приходит 200, а причина лежит в теле. Мониторинг, кэши и повторы на клиенте после этого не отличают успех от сбоя.

Описывают в спецификации только успешный ответ. Разработчик и тестировщик потом сами решают, что возвращать на 400, 404, 409 и 422, и каждый делает по-своему.