Какие знаешь статусы ошибки 400?

Статусы ошибки 4xx и их вариации

Ошибка 400 Bad Request является базовым клиентским статусом в семействе 4xx (Client Error), но существует множество его специализированных вариантов. Эти коды указывают, что проблема возникла на стороне клиента (например, браузера, мобильного приложения или другого API-клиента), и сервер не может или не будет обрабатывать запрос в его текущем виде.

Основные статусы, связанные с некорректным запросом (Bad Request Family)

1. 400 Bad Request

Базовый статус. Сервер не может обработать запрос из-за синтаксической ошибки, неверной структуры или нарушенной валидации. Причины:

• Неверный формат JSON или XML в теле запроса.
• Несоответствие схеме данных (например, ожидается число, а передана строка).
• Отсутствие обязательного параметра в запросе.

Пример невалидного JSON, который вызовет 400:

{
  "name": "Тест",
  "age": "двадцать пять" // Ожидается число (integer), а передана строка
}

2. 401 Unauthorized

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

• Часто сопровождается заголовком WWW-Authenticate.
• Важно: Этот код именно об аутентификации (кто вы?), а не о правах.

3. 403 Forbidden

Доступ запрещён. Сервер понял запрос и идентифицировал клиента, но у клиента недостаточно прав для выполнения действия.

• Пользователь аутентифицирован, но у него нет роли для доступа к ресурсу.
• Попытка удалить чужой контент.

4. 404 Not Found

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

• Несуществующий путь API (/api/v1/users/99999).
• Удалённая или перемещённая страница без редиректа.

5. 405 Method Not Allowed

Метод не разрешён. Запрос сделан с HTTP-методом (GET, POST, PUT, DELETE), который не поддерживается для данного эндпоинта.

• Попытка отправить POST на эндпоинт, который принимает только GET.
• Сервер должен вернуть заголовок Allow со списком разрешённых методов.

Пример ответа:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS

6. 408 Request Timeout

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

7. 409 Conflict

Конфликт. Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса на сервере.

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

8. 413 Payload Too Large / 414 URI Too Long

Размер запроса превышает лимиты, установленные сервером.

• 413 — слишком большое тело запроса (например, загрузка огромного файла).
• 414 — слишком длинный URL (часто из-за множества query-параметров).

9. 415 Unsupported Media Type

Неподдерживаемый тип данных. Сервер отказывается обработать запрос, потому что тело запроса имеет формат (MIME-тип), который не поддерживается целевым ресурсом.

• Отправка XML на эндпоинт, ожидающий только JSON.
• Неверный заголовок Content-Type.

10. 422 Unprocessable Entity (WebDAV)

Очень важный статус для REST API. Сервер понимает тип содержимого и синтаксис запроса, но не может обработать переданные инструкции.

• Семантические ошибки: отрицательный возраст, дата рождения в будущем, некорректный формат email.
• Часто возвращает детальную информацию об ошибках валидации для каждого поля.

Пример тела ответа 422:

{
  "errors": [
    {
      "field": "email",
      "message": "must be a valid email address"
    },
    {
      "field": "quantity",
      "message": "must be greater than 0"
    }
  ]
}

11. 429 Too Many Requests

Слишком много запросов. Клиент превысил лимит запросов за определённый промежуток времени (rate limiting). Важен для защиты API от злоупотреблений.

Почему важно различать эти статусы для QA Engineer

1. Точность тестирования: Понимание различий между, например, 400 и 422 позволяет точно проектировать негативные тест-кейсы и проверять, что API возвращает семантически правильный код, а не общий 400 на все случаи жизни.
2. Анализ логов и отладка: При анализе ошибок в продакшене можно быстро локализовать проблему: 409 — конфликт данных, 415 — проблема с клиентом, который отправляет не тот формат.
3. Тестирование безопасности: Статусы 401 и 403 критичны для тестирования контроля доступа. Неправильная их реализация (например, возврат 404 вместо 403 на запрещённый ресурс) может раскрывать информацию о системе.
4. Документирование API: QA часто участвует в ревью спецификаций. Знание стандартных кодов позволяет предложить разработчикам более точные и соответственные HTTP-статусы для различных сценариев ошибок.

Для полноценного тестирования REST API инженеру QA необходимо не только знать эти статусы, но и уметь:

• Генерировать запросы, которые будут их вызывать.
• Проверять не только код ответа, но и тело ответа (должно быть информативным для разработчика клиента).
• Верифицировать заголовки ответа (например, Allow для 405 или Retry-After для 429).
• Понимать, какой статус является наиболее корректным для конкретной бизнес-логики приложения.