Какие данные входят в заголовки HTTP при тестировании API?

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

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

Как отвечать

Разделите на заголовки запроса и ответа и к каждому добавьте, что вы с ним проверяете.

В запросе:

• Authorization: Bearer <токен> или Basic. Без него ждём 401, с токеном без прав 403;
• Content-Type: формат тела, application/json или multipart/form-data с boundary. На неподдерживаемый тип правильный ответ 415;
• Accept: какой формат клиент готов принять, при несовпадении возможен 406;
• Accept-Language, Accept-Encoding: локализация ответа и сжатие (gzip, br);
• служебные: X-Request-ID для поиска запроса в логах, Idempotency-Key для повторных платёжных запросов, If-None-Match для условных запросов.

В ответе:

• Content-Type и кодировка;
• Location после 201 Created или редиректа;
• Cache-Control, ETag: повторный запрос с If-None-Match должен вернуть 304;
• Set-Cookie: флаги HttpOnly, Secure, SameSite;
• WWW-Authenticate рядом с 401, Retry-After рядом с 429 и 503;
• CORS и безопасность: Access-Control-Allow-Origin, Strict-Transport-Security, X-Content-Type-Options: nosniff.

Инструменты: curl -i или -v, вкладка Headers в Postman, в REST Assured given().header(...) и then().header(...).

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

Путают 401 и 403. Первый значит «не знаю, кто вы», второй «знаю, но нельзя».

Сравнивают Content-Type на точное равенство и ловят ложное падение из-за ; charset=utf-8. Проверять стоит вхождение, а имена заголовков регистронезависимы: в HTTP/2 они вообще передаются строчными.

Ищут CORS-ошибки в Postman. Preflight-запрос OPTIONS отправляет только браузер, поэтому CORS проверяют отдельно, заголовком Origin в запросе.