Метод, статус-код и заголовки - это три самых полезных сигнала в HTTP-запросе и ответе. Очень часто QA может понять половину проблемы ещё до чтения body, просто посмотрев на эти три вещи.
Новички обычно концентрируются на данных в ответе: пришёл JSON, есть поле, нет поля. Это важно, но сначала нужно понять более базовый уровень: что клиент вообще хотел сделать, как сервер это интерпретировал и какой технический контекст сопровождал запрос. Именно это и показывают метод, статус-код и headers.
Если научиться читать их уверенно, расследование дефектов становится заметно быстрее.
Метод
HTTP method показывает намерение клиента. Не "что получилось", а что именно он пытался сделать.
- →GET - получить данные
- →POST - создать сущность или запустить действие
- →PUT - полностью заменить ресурс
- →PATCH - частично обновить ресурс
- →DELETE - удалить ресурс или перевести его в неактивное состояние
На практике команды иногда используют их неидеально, и это нормально учитывать. Но для QA всё равно важно видеть смысл. Если клиент делает GET, а в системе после этого меняются данные, это уже повод насторожиться. Если создание сущности идёт через GET, значит сломан не только стиль API, но и часть ожиданий по кэшированию, повторяемости и безопасности.
Ещё одна важная идея - идемпотентность. Некоторые методы можно повторить без изменения результата по смыслу, а некоторые нет. Для QA это полезно в ретраях, повторных кликах, нестабильной сети и автотестах. Если один и тот же запрос случайно отправился дважды, последствия для POST и PUT могут быть разными, и это нужно учитывать в проверках.
Статус-код
Статус-код - это короткий технический итог обработки запроса. Он не объясняет всё, но сразу показывает, в каком классе лежит результат.
- →1xx - промежуточная техническая информация
- →2xx - запрос обработан успешно
- →3xx - нужен редирект или дополнительный шаг
- →4xx - проблема в запросе, данных или доступе со стороны клиента
- →5xx - ошибка на стороне сервера
Для QA этого деления уже достаточно, чтобы быстро сориентироваться. Но сильный QA идёт глубже и понимает смысл самых частых кодов.
- →200 OK - запрос успешен
- →201 Created - сущность создана
- →204 No Content - операция успешна, но тела ответа нет
- →301 / 302 / 307 / 308 - редиректы
- →400 Bad Request - сервер не принимает запрос в текущем виде
- →401 Unauthorized - клиент не аутентифицирован как нужно
- →403 Forbidden - клиент распознан, но доступа нет
- →404 Not Found - ресурс не найден
- →409 Conflict - конфликт состояния
- →422 Unprocessable Content - структура запроса нормальная, но бизнес-смысл или данные не проходят проверку
- →500 Internal Server Error - внутренняя ошибка сервера
- →502, 503, 504 - проблемы на стыке сервисов, перегрузке или доступности
Важно не запоминать всю таблицу кодов, а понимать, как они помогают локализовать проблему.
Например: 401 и 403 - это не одно и то же. 404 может означать не только "нет такого URL", но и "нет такой сущности". 200 не гарантирует, что бизнес-логика сработала правильно. А 500 не говорит, где именно упало, но быстро показывает, что проблема не в форме на frontend.
Почему 200 OK ещё ничего не гарантирует
Одна из самых частых ловушек - считать, что если API вернул 200, значит всё хорошо.
- →отдать неверные данные
- →вернуть пустой список там, где ожидался объект
- →замаскировать бизнес-ошибку в поле error
- →частично выполнить операцию, но не довести её до конца
- →прислать устаревшие данные из кэша
Поэтому QA всегда читает статус-код вместе с телом ответа и контекстом сценария. Технический успех не равен продуктовому успеху.
Заголовки
Headers - это дополнительный контекст запроса и ответа. Они часто кажутся второстепенными, пока не начинаешь разбирать реальные проблемы.
- →тип данных (Content-Type)
- →ожидаемый формат ответа (Accept)
- →авторизация (Authorization)
- →cookie
- →язык или locale
- →кэширование (Cache-Control, ETag, If-None-Match)
- →корреляционные идентификаторы
- →CORS-политики
- →security-политики
Для QA headers особенно важны потому, что именно здесь часто сидят причины "странных" багов.
- →backend ждёт application/json, а клиент отправил другой Content-Type
- →токен есть, но улетел не в тот header
- →cookie не дошла или не сохранилась
- →кэш отдал старую версию данных
- →браузер заблокировал запрос из-за CORS
- →reverse proxy переписал часть заголовков
- →локаль в запросе одна, а в ответе другая
То есть headers - это не декоративная часть протокола. Это важный слой контекста, без которого запрос может быть технически "нормальным", но логически неправильным.
Как это помогает QA на практике
Представь баг: пользователь не может сохранить профиль.
Если смотреть только на UI, видно одно сообщение об ошибке. Если смотреть на HTTP-сигналы, картина может быть совсем разной:
- →PATCH ушёл, но сервер ответил 400 из-за невалидного поля
- →запрос вообще ушёл как POST, а backend ждёт PATCH
- →сервер вернул 403, потому что у роли нет нужного права
- →клиент отправил неправильный Content-Type
- →операция успешна, но frontend не умеет обрабатывать 204 No Content
- →запрос проходит, но кэш или повторная загрузка страницы показывает старые данные
Внешне это всё может выглядеть как один баг "не сохраняется профиль". Но для команды это шесть разных классов проблем. И именно метод, статус-код и headers помогают быстро понять, куда копать.
Что важно QA
- →какой method использован
- →какой URL вызван
- →какие ключевые headers ушли
- →какой статус вернулся
- →какие headers пришли обратно
- →соответствует ли body смыслу сценария
Если делать так системно, со временем ты перестаёшь смотреть на сетевой лог как на "шум" и начинаешь видеть в нём структуру.
Что должен вынести QA из этой темы
- →Метод показывает намерение клиента.
- →Статус-код показывает технический результат обработки.
- →Headers передают критичный контекст запроса и ответа.
- →200 OK не гарантирует, что бизнес-сценарий отработал правильно.
- →Много дефектов локализуются быстрее, если читать method, status и headers вместе, а не по отдельности.
Что ещё почитать
- →Внутри базы: HTTP и HTTPS
- →Внутри базы: Аутентификация и авторизация
- →Внешний материал: MDN HTTP response status codes