Какие знаешь статус-коды 4xx?

HTTP Статус-коды 4xx: Ошибки на стороне клиента

Статус-коды серии 4xx указывают на ошибки, вызванные некорректным запросом со стороны клиента. Это один из ключевых аспектов тестирования HTTP API, который QA-инженер должен хорошо понимать.

Основные статус-коды 4xx

400 Bad Request

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

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

При тестировании API проверяем отправку невалидных данных и убеждаемся, что сервер вернёт именно 400.

401 Unauthorized

Отсутствует или невалидна аутентификация. Когда это возникает:

• Запрос без авторизационного токена
• Просроченный или поддельный JWT
• Неверные учётные данные (логин/пароль)

В тестировании проверяем защищённые эндпоинты без авторизации, с неверным токеном, с истекшей сессией.

403 Forbidden

Авторизация успешна, но пользователю недостаточно прав. Различие от 401:

• Пользователь аутентифицирован, но не авторизован
• Например, обычный пользователь пытается удалить другого пользователя
• Администратор заблокирован от определённого действия

Тестируем разные роли пользователей (user, admin, moderator) и их доступ к ресурсам.

404 Not Found

Ресурс не найден на сервере. Сценарии:

• Запрос к несуществующему пути API
• Попытка получить пользователя с id, которого нет в БД
• Удалённый или перемещённый ресурс

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

409 Conflict

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

• Попытка создать пользователя с email, который уже существует
• Изменение ресурса, который в процессе редактирования другим пользователем
• Нарушение уникального constraint'а в БД

422 Unprocessable Entity

Сервер понимает контент-тип и синтаксис верны, но не может обработать из-за семантической ошибки:

• Email не валидный по формату
• Возраст вне допустимого диапазона
• Дата окончания раньше даты начала

Это отличается от 400 тем, что здесь запрос синтаксически правильный, но логически невозможный.

429 Too Many Requests

Ограничение частоты запросов (rate limiting) превышено. Важно для:

• Защиты от DDoS атак
• Предотвращения перегрузки сервера
• Контроля использования API

В тестировании проверяем поведение при отправке большого количества запросов подряд.

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

При тестировании API всегда проверяем:

1. Позитивные сценарии — корректные запросы должны пройти
2. Граничные значения — тестируем мин/макс значения
3. Невалидные данные — ожидаем 400 или 422
4. Отсутствие авторизации — ожидаем 401
5. Недостаточные права — ожидаем 403
6. Несуществующие ресурсы — ожидаем 404
7. Конфликты — ожидаем 409 при нарушении бизнес-логики

Понимание этих статус-кодов критически важно для написания качественных автотестов и проведения ручного тестирования.