Из чего состоит HTTP-запрос на бэкенд, включая headers и body

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

Умеете ли вы читать запрос в панели разработчика и составлять его руками. Для тестировщика это база: без неё невозможно ни воспроизвести дефект, ни описать его.

Как отвечать

Запрос состоит из стартовой строки, заголовков и тела.

Стартовая строка: метод, путь с параметрами и версия протокола. Например POST /api/jobs?draft=true HTTP/1.1. Метод задаёт намерение, путь адресует ресурс, параметры запроса обычно фильтруют или уточняют.

Заголовки это метаданные, и по ним чаще всего и проходит разбор дефекта:

• Host (обязателен), Content-Type (в каком формате тело), Content-Length или признак поблочной передачи;
• Authorization с токеном, Cookie с сессией;
• Accept и Accept-Language, по которым сервер выбирает формат и язык ответа;
• User-Agent, Referer, Origin, а также свои заголовки вроде идентификатора запроса для сквозной трассировки;
• условные (If-None-Match, If-Modified-Since) для кеширования.

Тело есть не всегда: у GET и HEAD его обычно нет, у POST, PUT и PATCH оно несёт данные. Форматы: JSON, форма с полями, многочастная форма для файлов, реже XML.

Полезно назвать практику тестировщика: воспроизводить запрос через curl или Postman, копируя его из панели разработчика; сверять Content-Type с реальным телом (частая причина ошибки 400 и 415); проверять поведение при отсутствующих и лишних заголовках; помнить, что чувствительные данные не должны уходить в параметрах пути, потому что те попадают в логи и историю.

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

Путают параметры запроса и тело: первые видны в логах и истории браузера, вторые нет.

Считают, что заголовки необязательны: без правильного Content-Type сервер не разберёт тело.

Не различают Authorization и Cookie и не понимают, почему запрос из панели работает, а из Postman нет.