С какими 4xx ошибками вы чаще всего сталкивались?

Что проверяют

Не заучен ли список кодов, а понимаете ли вы, что 4xx это ответственность вызывающей стороны, и умеете ли по коду локализовать дефект. Для тестировщика это ещё и вопрос о том, какой баг вы заведёте и на кого: на бэкенд, на клиент или на документацию.

Как отвечать

Начните с деления: 4xx значит, что сервер понял запрос и отказал по вине клиента, 5xx что сломался сам. Дальше по кодам, с признаком, как отличать:

• 400: некорректный запрос, битый JSON, неверный тип параметра;
• 401: аутентификации нет или токен просрочен, в ответе ожидается WWW-Authenticate;
• 403: кто вы, известно, но прав на действие нет;
• 404: ресурс не найден, иногда так же маскируют отсутствие прав;
• 405: метод не тот, в ответе ожидается Allow со списком разрешённых;
• 409: конфликт состояния, дубликат или гонка;
• 415: неподходящий Content-Type;
• 422: синтаксис верный, бизнес-валидация не прошла;
• 429: сработало ограничение частоты, смотрите Retry-After.

Главное в ответе не длина списка, а пары, которые вы умеете различать: 401 против 403, 400 против 422, 404 против 403. Расскажите, как проверяете: повторяете запрос в клиенте API, убираете по одному обязательному полю, подменяете токен на чужой и на просроченный, шлёте несуществующий метод, превышаете лимит.

Полезно добавить, что в отчёт идёт не только код, а тело ответа, заголовки и идентификатор запроса, по которому разработчик найдёт вызов в логах.

Где спотыкаются

Говорят, что 401 это «нет прав». 401 про то, что система вас не опознала, а 403 про то, что опознала и запретила. Перепутанная пара уводит расследование в чужую подсистему.

Считают 4xx не багом, потому что «сервер жив». Если валидный по документации запрос получает 400, баг на сервере; если клиент шлёт заведомо неверный запрос, баг на клиенте; если расходится с документацией, баг в документации.

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