Какой статус код при поломке клиента?

Статус-коды при "поломке клиента": разбор класса 4xx

Вопрос "Какой статус код при поломке клиента?" требует важного уточнения. Единого статус-кода на все случаи "поломки клиента" не существует. Под "поломкой" обычно подразумевается ошибка на стороне клиента, что соответствует классу HTTP статус-кодов 4xx (Client Error). Сервер получил корректный, но некорректный с точки зрения логики или синтаксиса запрос, который не может быть выполнен. Ответственность за исправление лежит на клиенте (браузере, приложении, скрипте).

Конкретный код зависит от типа ошибки. Вот основные статус-коды для типичных "поломок":

1. 400 Bad Request (Плохой запрос)

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

• Пример "поломки": Клиент отправил JSON с синтаксической ошибкой (пропущена кавычка, запятая), неверный формат данных в теле запроса, нарушение протокола.
• Что проверять в QA: Валидацию входных данных на стороне клиента и сервера, корректность формирования запросов API.

// Пример запроса, который может привести к 400
POST /api/user
Content-Type: application/json

{
    "name": "Ivan",
    "email": "ivan@example.com"  // Ошибка: пропущена закрывающая кавычка
}

2. 401 Unauthorized (Не авторизован)

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

• Пример "поломки": Пользователь вводит неправильный логин/пароль, пытается получить доступ к защищенному ресурсу без отправки токена, срок действия токена истек.
• Что проверять в QA: Механизмы логина, обработку просроченных и невалидных токенов, корректность хранения учетных данных на клиенте.

3. 403 Forbidden (Запрещено)

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

• Пример "поломки": Пользователь с ролью "читатель" пытается отправить POST-запрос на удаление статьи через API или получить доступ к админ-панели.
• Что проверять в QA: Систему ролей и разрешений (RBAC), проверку прав доступа к разным endpoint'ам.

4. 404 Not Found (Не найдено)

Классическая ошибка. Сервер не нашел запрашиваемый ресурс.

• Пример "поломки": Пользователь вручную ввел несуществующий URL, клиентское приложение формирует запрос к удаленному или переименованному API endpoint'у, ссылка на несуществующий файл (изображение, скрипт).
• Что проверять в QA: Корректность роутинга, обработку несуществующих ID в запросах (например, GET /api/products/999999), "битые" ссылки.

5. 422 Unprocessable Entity (Необрабатываемая сущность)

Более специфичная ошибка, чем 400. Запрос синтаксически корректен, но содержит семантические ошибки. Часто используется в REST API при валидации бизнес-логики.

• Пример "поломки": Отправка данных, нарушающих уникальность поля (например, email, который уже существует), неверный формат данных (дата из будущего для поля "дата рождения"), несоответствие типа данных ожидаемому.
• Что проверять в QA: Валидацию сложных бизнес-правил на сервере, корректность возвращаемых деталей ошибки в теле ответа.

// Пример ответа с кодом 422
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
    "errors": {
        "email": ["Этот адрес электронной почты уже занят."],
        "age": ["Возраст должен быть положительным числом."]
    }
}

6. 429 Too Many Requests (Слишком много запросов)

Клиент превысил лимит запросов за определенный промежуток времени (rate limiting).

• Пример "поломки": Скрипт клиента содержит ошибку, приводящую к бесконечному циклу запросов, пользователь агрессивно обновляет страницу (F5), бот пытается перебрать данные.
• Что проверять в QA: Настройки и работу механизма ограничения запросов, корректность заголовков Retry-After в ответе.

Вывод для QA-инженера

Нельзя сказать, что "поломка клиента" — это всегда один код. Ваша задача как QA — понимать контекст ошибки и знать, какой статус-код ожидать в каждом конкретном сценарии. При тестировании API и веб-приложений:

1. Проверяйте негативные сценарии — отправляйте неверные, неполные или некорректные данные.
2. Валидируйте ответы сервера — проверяйте не только факт возврата ошибки 4xx, но и корректность самого кода (например, при недостатке прав должен быть 403, а не 404 или 401), а также полезное тело ответа с описанием проблемы.
3. Сверяйтесь с документацией API — в спецификации (OpenAPI/Swagger) обычно четко указаны возможные коды ответов для каждого endpoint'а.

Таким образом, при "поломке клиента" сервер должен ответить соответствующим 4xx статус-кодом, который точно описывает проблему, помогая клиентской части (и разработчикам) быстро её диагностировать и устранить.