Когда возникает статус код четыреста?

Обзор статус кода 4xx

Статус кода 4xx возникают, когда сервер определяет, что ошибка исходит со стороны клиента (браузера, мобильного приложения, скрипта и т.д.). Диапазон 4xx сигнализирует об "ошибках клиента" (Client Error). В отличие от 5xx (ошибки сервера), ответственность за возникновение и, как правило, за исправление таких ошибок лежит на стороне отправителя запроса.

Основные причины возникновения

Статус 4xx возникает в следующих типичных сценариях:

• Некорректный синтаксис запроса: Запрос составлен с нарушением протокола HTTP (например, неверный формат заголовков, пустая строка между заголовками в неположенном месте).
• Невалидные данные: Клиент отправляет данные, которые сервер не может принять или обработать (неверный формат JSON, отсутствие обязательного поля, значение поля за пределами допустимого диапазона).
• Проблемы с аутентификацией или авторизацией: У клиента нет или недостаточно прав для доступа к ресурсу.
• Нарушение бизнес-логики: Запрос логически противоречит правилам системы (например, попытка списать больше товара, чем есть на складе).
• Конфликты ресурсов: Попытка создать или изменить ресурс, который конфликтует с текущим состоянием сервера.
• Доступ к несуществующим ресурсам: Самый частый случай — обращение по неверному URL.

Наиболее распространённые статусы 4xx и примеры их возникновения

Вот ключевые представители этой группы с практическими примерами:

1. 400 Bad Request

Общий статус для некорректного запроса, когда сервер не может его обработать из-за клиентской ошибки (например, неверный синтаксис).

• Пример: Отправка JSON с синтаксической ошибкой.

// Клиент отправил:
{
    "name": "Test",
    "price": "десять" // Ожидается число, а передана строка
}

// Сервер может ответить 400, если валидация строгая.

2. 401 Unauthorized

Требуется аутентификация. Клиент не предоставил или предоставил неверные учётные данные.

• Пример: Попытка доступа к /api/admin без отправки заголовка Authorization: Bearer <token>.

3. 403 Forbidden

Сервер понял запрос, но отказывается его авторизовать. Аутентификация прошла, но прав недостаточно.

• Пример: Пользователь с ролью "читатель" пытается отправить POST-запрос для создания статьи.

4. 404 Not Found

Самый узнаваемый статус. Сервер не нашёл запрашиваемый ресурс.

• Пример: Обращение к несуществующему URL, например, GET /api/products/99999, где товара с таким ID нет в базе.

5. 405 Method Not Allowed

Метод запроса известен серверу, но не поддерживается для целевого ресурса.

• Пример: Отправка DELETE запроса на эндпоинт /api/users, который поддерживает только GET и POST. В заголовке Allow ответа сервер должен указать разрешённые методы.

6. 409 Conflict

Запрос конфликтует с текущим состоянием сервера.

• Пример: Попытка создать пользователя с email, который уже зарегистрирован в системе.
• Другой пример (оптимистичная блокировка):

PUT /api/document/123
If-Match: "a1b2c3d4" // Версия документа у клиента
Content-Type: application/json

{"title": "New Title"}

Если на сервере версия документа уже другая, он вернёт 409 Conflict, так как клиентские данные устарели.

7. 422 Unprocessable Entity (из спецификации WebDAV, но широко используется в REST API)

Сервер понимает тип содержимого запроса и его синтаксис корректен, но не может обработать содержащиеся инструкции. Часто используется для ошибок валидации бизнес-логики.

• Пример: Отправка формы регистрации, где пароль слишком короткий, а дата рождения — из будущего. Тело ответа обычно содержит детали ошибок.

// Ответ сервера 422 Unprocessable Entity
{
  "errors": [
    {
      "field": "password",
      "message": "Длина пароля должна быть не менее 8 символов"
    },
    {
      "field": "birthDate",
      "message": "Дата рождения не может быть в будущем"
    }
  ]
}

8. 429 Too Many Requests

Клиент отправил слишком много запросов за заданный промежуток времени (Rate Limiting).

• Пример: Публичный API ограничивает число вызовов до 100 в час. После превышения лимита возвращается 429.

Роль QA-инженера в тестировании ответов 4xx

Для QA-инженера важно не только знать эти статусы, но и активно проверять, что приложение возвращает корректные и информативные ответы:

1. Проверка валидации: Намеренно отправлять невалидные, неполные, некорректно форматированные данные и проверять, что возвращается ожидаемый статус (чаще 400 или 422) с понятным сообщением.
2. Проверка контроля доступа: Тестировать сценарии с недостаточными правами (403), без авторизации (401) и доступ к несуществующим объектам (404).
3. Анализ тела ответа: Убедиться, что в теле ошибки (обычно в формате JSON) есть структурированная информация для отладки (код ошибки, сообщение, список полей), но без утечки чувствительных данных (путей к файлам, стека вызовов на продакшене).
4. Проверка бизнес-конфликтов: Моделировать ситуации, приводящие к 409 (дублирование, одновременное изменение).
5. Тестирование лимитов: Проверять работу механизма Rate Limiting (429).

Вывод: Статусы 4xx — это crucial-индикаторы корректности взаимодействия клиента с API. Их правильная обработка со стороны сервера и клиента напрямую влияет на безопасность, надёжность и удобство отладки всего приложения. Задача QA — убедиться, что сервер правильно классифицирует ошибки клиента и понятно сообщает о них.