Какие коды ответа HTTP вы знаете? Что они означают?

Основные категории кодов состояния HTTP

Коды состояния HTTP (Status Codes) являются стандартизированным способом информирования клиента о результате выполнения его запроса к серверу. Они разделены на пять классов, обозначаемых первой цифрой кода.

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

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

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

2xx: Успешные коды (Success)

Запрос был успешно получен, понят и принят сервером.

• 200 OK: Стандартный ответ на успешные запросы (GET, POST, PUT, PATCH). Ответ обычно содержит тело с запрошенными данными.

  // Пример ответа для GET /api/users/1
  {
    "id": 1,
    "name": "Иван Иванов"
  }
  

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

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

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

• 301 Moved Permanently: Запрашиваемый ресурс был навсегда перемещен на новый URL. Поисковики обновляют индекс.
• 302 Found (ранее "Moved Temporarily"): Ресурс временно доступен по другому URI. Клиент должен использовать оригинальный URL для будущих запросов.
• 304 Not Modified: Используется для кэширования. Клиент запросил ресурс с условиями (заголовки If-Modified-Since, If-None-Match), и ресурс не изменился. Сервер возвращает только метаданные без тела.

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

Запрос содержит неправильный синтаксис или не может быть выполнен по вине клиента.

• 400 Bad Request: Общая ошибка, означающая, что сервер не может обработать запрос из-за некорректного синтаксиса (например, неверный JSON в теле).

  // Пример запроса, который может вызвать 400
  POST /api/data HTTP/1.1
  Content-Type: application/json
  
  {"name": "test" // Ошибка: пропущена закрывающая фигурная скобка
  

• 401 Unauthorized: Для доступа к ресурсу требуется аутентификация. Клиент должен представиться.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать. Аутентификация не поможет (недостаточно прав).
• 404 Not Found: Наиболее известный код. Сервер не может найти запрошенный ресурс по указанному URI.
• 405 Method Not Allowed: Метод запроса (GET, POST и т.д.) не поддерживается для данного URI (например, попытка POST к эндпоинту, который принимает только GET).
• 409 Conflict: Запрос конфликтует с текущим состоянием ресурса (например, попытка обновить данные устаревшей версией).
• 429 Too Many Requests: Клиент превысил лимит запросов за определенное время (Rate Limiting).

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

Сервер не смог выполнить действительно корректный запрос из-за внутренней ошибки.

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

Значимость для QA-инженера

Понимание HTTP-кодов критически важно для эффективного тестирования API и веб-приложений.

• Верификация позитивных сценариев: Убедиться, что успешные операции возвращают корректные коды (200, 201, 204).
• Тестирование негативных сценариев и обработки ошибок: Проверка, что при неверных данных, отсутствии прав или ресурсов возвращаются ожидаемые коды 4xx с понятными сообщениями в теле.
• Анализ логов и диагностика проблем: Коды 5xx сразу указывают на проблемы на стороне сервера, что помогает локализовать дефект.
• Тестирование граничных условий и безопасности: Проверка лимитов запросов (429), корректности перенаправлений (3xx) и запрета доступа (403).
• Написание автотестов: Автоматизированные проверки обязательно должны включать валидацию кода состояния ответа.

  # Пример проверки в автотесте на Python (pytest + requests)
  def test_get_user_success():
      response = requests.get('/api/users/1')
      assert response.status_code == 200
      assert response.json()['name'] == 'Иван Иванов'
  
  def test_create_user_validation_error():
      payload = {"email": "invalid-email"} # Некорректный email
      response = requests.post('/api/users', json=payload)
      # Ожидаем, что валидация на стороне сервера вернет 400
      assert response.status_code == 400
      assert "email" in response.json()['errors']
  

Таким образом, детальное знание HTTP-кодов позволяет QA-инженеру не только грамотно проектировать тестовое покрытие, но и эффективно коммуницировать с разработчиками, точно описывая поведение системы.