Какие знаешь семейства кодов ответов?

Семейства кодов ответов HTTP

Протокол HTTP использует трехзначные цифровые коды состояния (Status Codes) для информирования клиента о результате его запроса. Эти коды сгруппированы в пять основных семейств, где первая цифра определяет класс ответа. Понимание этих семейств критически важно для QA Engineer, так как позволяет корректно интерпретировать поведение системы, проектировать тестовые сценарии, валидировать API и анализировать логи.

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

Эти коды указывают на промежуточный статус обработки запроса. Они информируют клиента о том, что запрос принят и обработка продолжается. На практике в ручном тестировании встречаются редко, но важны для понимания работы протокола.

• 100 Continue: Сервер готов принять тело запроса. Клиент должен отправить оставшуюся часть.
• 101 Switching Protocols: Сервер соглашается сменить протокол (например, на WebSocket).
• 102 Processing (WebDAV): Сервер обрабатывает запрос, но ответ еще не готов.

2xx: Коды успеха (Success)

Наиболее желаемые коды, означающие, что запрос клиента был успешно получен, понят и обработан.

• 200 OK: Стандартный ответ на успешный GET, POST, PUT или DELETE запрос.
• 201 Created: Запрос выполнен, и в результате был создан новый ресурс (часто после POST).
• 202 Accepted: Запрос принят на обработку, но она еще не завершена (асинхронные операции).
• 204 No Content: Сервер успешно обработал запрос, но не возвращает никакого контента (например, после DELETE).

// Пример успешного ответа 200 OK от API
{
  "status": 200,
  "data": {
    "userId": 1,
    "id": 1,
    "title": "delectus aut autem",
    "completed": false
  }
}

3xx: Коды перенаправления (Redirection)

Указывают клиенту на необходимость предпринять дополнительные действия для завершения запроса (обычно – выполнить новый запрос по другому URI).

• 301 Moved Permanently: Ресурс навсегда перемещен по новому URI. Для тестирования важно: проверять, обновлены ли ссылки у клиента.
• 302 Found (или 307 Temporary Redirect): Ресурс временно доступен по другому URI. Важно для безопасности тестов: при POST запросе повторный запрос не должен автоматически менять метод на GET (это отличие 307 от 302).
• 304 Not Modified: Используется для кеширования. Клиент может использовать кешированную версию ресурса.

4xx: Коды ошибки клиента (Client Error)

Указывают, что ошибка произошла по вине клиента (например, неверный синтаксис запроса, отсутствие прав, некорректные параметры). Это ключевая область для тестирования негативных сценариев и валидации входных данных.

• 400 Bad Request: Сервер не может обработать запрос из-за неверного синтаксиса (например, невалидный JSON).
• 401 Unauthorized: Требуется аутентификация для доступа к ресурсу.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (прав недостаточно).
• 404 Not Found: Сервер не может найти запрашиваемый ресурс. Один из самых частых кодов при тестировании.
• 429 Too Many Requests: Клиент отправил слишком много запросов за заданное время (Rate Limiting).

# Пример ответа 400 при неверном теле запроса
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Validation failed",
  "details": ["Field 'email' is required"]
}

5xx: Коды ошибки сервера (Server Error)

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

• 500 Internal Server Error: Общий шаблонный ответ на непредвиденную ошибку сервера.
• 502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недопустимый ответ от вышестоящего сервера.
• 503 Service Unavailable: Сервер временно не может обрабатывать запросы (перегрузка, техобслуживание).
• 504 Gateway Timeout: Таймаут ожидания ответа от вышестоящего сервера.

Для QA Engineer глубокое знание этих семейств позволяет:

• Проектировать точные тест-кейсы (позитивные/негативные, проверка граничных значений для API).
• Анализировать логи сервера и клиента для диагностики проблем.
• Тестировать отказоустойчивость и обработку ошибок (например, как ведет себя фронтенд при 500 или 503 ответе).
• Валидировать корректность реализации бизнес-логики (правильный ли код возвращается при отсутствии прав: 401 vs 403).
• Проверять корректность кеширования и редиректов (3xx коды).

Понимание разницы между, например, 400 и 422 (Unprocessable Entity), или между 401 и 403, часто является темой для углубленных вопросов на собеседовании и ключом к эффективному тестированию RESTful API.