Коды ответов HTTP: что означают и как проверять
Язык, на котором браузер разговаривает с сервером. Разбираем структуру запроса и учимся читать коды ответов. С тренажёром.
Всё, что происходит между браузером и сервером, — это запросы и ответы по протоколу HTTP. Умение их читать превращает тестировщика из «пользователя с чек-листом» в человека, который понимает, где сломалось.
Структура запроса
Структура ответа
HTTP/1.1 201 Created ← код и его расшифровка
Content-Type: application/json
Location: /api/orders/5002
{"id": 5002, "status": "new", "total": 15980}Методы
| Метод | Смысл | Меняет данные | Повтор безопасен |
|---|---|---|---|
| GET | Получить | Нет | Да |
| POST | Создать / выполнить действие | Да | Нет |
| PUT | Заменить целиком | Да | Да |
| PATCH | Изменить частично | Да | Обычно да |
| DELETE | Удалить | Да | Да (второй раз — 404) |
Повторите POST-запрос дважды (кнопка Retry в DevTools или повторная отправка формы). Если создались два одинаковых заказа — у продукта нет защиты от дублей. Это Critical: пользователю спишут деньги дважды.
Коды ответов
- 1xx — информационные, встречаются редко.
- 2xx — успех. 200 OK, 201 Created (создано), 204 No Content (успех без тела).
- 3xx — перенаправление. 301 навсегда, 302/307 временно.
- 4xx — проблема на стороне запроса. 400 неверный запрос, 401 не аутентифицирован, 403 нет прав, 404 не найдено, 405 метод не поддерживается, 409 конфликт, 422 не проходит бизнес-правило, 429 слишком много запросов.
- 5xx — проблема на сервере. 500 внутренняя ошибка, 502/504 проблемы шлюза, 503 сервис недоступен.
Даже если вы отправили «дурацкие» данные. Сервер обязан отвечать понятной ошибкой 4xx, а не падать. Ответ 500 на кривой ввод — законный баг, и его не должен закрывать аргумент «так никто делать не будет».
Тренажёр: коды ответов
Практическая часть урока выполняется в браузере с проверкой результата. Попробовать бесплатно: тренажёр по вёрстке или зарегистрируйтесь — откроются уроки и тренажёры курса.
Заголовки, которые встречаются постоянно
Content-Type— формат тела:application/json,multipart/form-data(загрузка файлов).Authorization— токен доступа. Классическая проверка: отправить запрос без него.Set-Cookie/Cookie— сессия.Cache-Control— правила кэширования. Причина «старых данных на экране».Location— адрес созданного или нового ресурса.Retry-After— когда можно повторить после 429 или 503.
Что проверять на уровне HTTP
- Правильный ли метод для действия (создание — POST, а не GET).
- Приходит ли корректный код ответа в каждом сценарии, включая ошибки.
- Есть ли в ответе понятное описание ошибки (не только код).
- Работают ли запросы без авторизации и с чужим токеном — что вернётся.
- Что произойдёт при повторе, при параллельной отправке, при обрыве соединения.
- Не уходят ли в запросах лишние данные: пароли в открытом виде, чужие идентификаторы.
Это урок из курса «Ручной тестировщик»
В курсе 47 уроков и 36 тренажёров: тест-дизайн, вёрстка и UX, DevTools, API, SQL, Git и работа со стендом. Несколько уроков открыты бесплатно после регистрации.