Какие знаешь группы статус-кодов?

Какие знаешь группы статус-кодов?

HTTP статус-коды — это трёхзначные числовые коды, которые сервер отправляет в ответе на запрос клиента. Они указывают на результат обработки запроса и являются критически важными для тестирования API и веб-приложений. Все коды разделены на пять групп по первой цифре.

1xx — Informational (Информационные)

Эти коды указывают на промежуточное состояние запроса. Сервер ещё обрабатывает, но первая часть получена и принята.

• 100 Continue — сервер получил начало запроса, клиент может продолжать отправку тела
• 101 Switching Protocols — переключение на другой протокол (например, WebSocket)

В QA эти коды встречаются редко, но важно знать при тестировании long-polling или WebSocket соединений.

2xx — Success (Успешные)

Самые желанные коды! Они означают, что запрос был успешно обработан.

• 200 OK — стандартный ответ на успешный запрос
• 201 Created — ресурс успешно создан (используется при POST с созданием)
• 202 Accepted — запрос принят но ещё обрабатывается (асинхронные операции)
• 204 No Content — успех, но тело ответа пусто (например, DELETE, успешный PATCH)
• 206 Partial Content — часть контента отправлена (например, при download с resume)

При тестировании API проверяйте, что функции возвращают правильные 2xx коды в соответствии с операцией.

3xx — Redirection (Перенаправление)

Эти коды означают, что для завершения запроса нужно дополнительное действие — обычно перейти на другой URL.

• 300 Multiple Choices — несколько вариантов доступны
• 301 Moved Permanently — ресурс перемещен на новый URL навсегда (браузер кеширует)
• 302 Found — временное перенаправление на другой URL
• 304 Not Modified — ресурс не изменился (кеш всё ещё актуален)
• 307 Temporary Redirect — как 302, но клиент НЕ должен менять метод запроса
• 308 Permanent Redirect — как 301, но клиент НЕ должен менять метод запроса

При тестировании важно проверяйте правильность редиректов и кеширования. 301 vs 302 — большая разница для SEO и производительности.

4xx — Client Error (Ошибка клиента)

Ошибки, вызванные неправильным запросом от клиента. Сервер говорит: проблема в тебе.

• 400 Bad Request — синтаксическая ошибка в запросе (некорректный JSON, неправильные параметры)
• 401 Unauthorized — требуется аутентификация (нет или истёк токен)
• 403 Forbidden — аутентифицирован, но нет прав (permission denied)
• 404 Not Found — ресурс не найден
• 405 Method Not Allowed — этот метод не допущен (например, DELETE на read-only ресурс)
• 408 Request Timeout — клиент слишком долго отправлял запрос
• 409 Conflict — конфликт (например, попытка создать уже существующий ресурс)
• 410 Gone — ресурс удалён и больше не вернётся
• 422 Unprocessable Entity — синтаксис корректен, но семантика невалидна (например, email не формата email)
• 429 Too Many Requests — rate limiting (слишком много запросов)

При QA тестировании обязательно проверяйте обработку 4xx ошибок: валидация, обработка исключений, корректные сообщения об ошибках.

5xx — Server Error (Ошибка сервера)

Ошибки на стороне сервера. Сервер говорит: проблема во мне.

• 500 Internal Server Error — неожиданная ошибка на сервере (обычно исключение)
• 501 Not Implemented — функция не реализована
• 502 Bad Gateway — gateway/proxy получил некорректный ответ от upstream сервера
• 503 Service Unavailable — сервер временно недоступен (maintenance, перегрузка)
• 504 Gateway Timeout — gateway ждал ответа от upstream слишком долго

При тестировании проверяйте graceful degradation при 5xx ошибках, логирование, алерты на monitoring.

Практическое применение в QA

API тестирование:

• Проверяйте, что каждый endpoint возвращает правильный статус-код
• Используйте Postman, REST Client для быстрой проверки
• Автоматизируйте проверку статус-кодов в pipeline

Обработка ошибок:

• Убедитесь, что UI красиво обрабатывает все ошибки (не показывает raw ошибку)
• Проверяйте retry логику при 5xx
• Тестируйте offline mode при отсутствии соединения

Performance и нагрузочное тестирование:

• Следите за увеличением 5xx при нагрузке
• Проверяйте, что 429 (rate limit) работает правильно

Security тестирование:

• 401 vs 403 должны быть отличимы (не должны быть 404 для скрытия существования ресурса в sensitive местах)
• Проверяйте, что 422 сообщения не раскрывают внутреннюю структуру

Знание групп статус-кодов — базовый скилл QA-инженера при работе с HTTP API и веб-приложениями.