Какой HTTP код ошибки подходит для ошибки в данных запроса
Что проверяют
Для аналитика это вопрос не про заучивание кода, а про умение спроектировать поведение API на ошибках и описать его так, чтобы фронтенд, бэкенд и тестирование поняли одинаково. Следом обычно просят показать, как это выглядит в спецификации.
Как отвечать
Ответ по умолчанию: 400 Bad Request, ошибка на стороне клиента, запрос в таком виде обработать нельзя. Затем разведите близкие случаи:
- 400: синтаксис и формат. Невалидный JSON, нет обязательного поля, строка вместо числа, дата не в формате ISO 8601;
- 422 Unprocessable Content: формат верный, но нарушено бизнес-правило. Сумма перевода больше лимита, дата доставки в прошлом;
- 409 Conflict: данные корректны, но конфликтуют с состоянием системы. Логин уже занят, заказ уже оплачен;
- 404: не найден ресурс из URL, а не значение поля в теле запроса.
Коды 401 и 403 про аутентификацию и права, к ошибкам в данных отношения не имеют.
Главное, что показывает аналитик: решение фиксируется в документации. В OpenAPI у каждого метода описывается блок responses с кодами и схемой тела ошибки. Хорошая практика: единый формат на весь API, например Problem Details по RFC 9457 (type, title, status, detail) плюс массив ошибок по полям с машинным кодом вроде AMOUNT_EXCEEDS_LIMIT. По такому коду фронтенд показывает понятный текст на нужном языке, а не пересказывает сообщение сервера. К формату прикладывают каталог ошибок, где каждому коду сопоставлены HTTP-статус и текст для пользователя.
Если выбор между 400 и 422 спорный, назовите правило, по которому решали, и скажите, что единообразие важнее конкретной цифры.
Где спотыкаются
Описывают только успешный ответ. Разработчики придумывают ошибки сами, и в одном API появляются три разных формата.
Предлагают 200 OK с полем success: false. Такой ответ ломает мониторинг, повторы запросов и логику клиентов, которые смотрят на статус.
Путают 400 и 403. Неверные данные не запрет доступа, и по 403 клиент начнёт разбираться с правами, а не с формой.