Что такое HTTP коды ответов и их группы

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

Умеете ли вы описывать поведение системы так, чтобы одинаково поняли разработка, тестирование и внешний интеграционный партнёр. Для аналитика коды ответов это не справочник, а часть постановки: каждая ветка сценария получает свой статус, иначе его придумает разработчик, и у трёх сервисов он окажется разным.

Как отвечать

Сначала группировка по первой цифре: 1xx промежуточные, 2xx успех, 3xx перенаправление, 4xx вина запроса, 5xx сбой на стороне сервиса. Ключевой смысл границы между четвёртой и пятой группой: по 4xx повторять запрос бессмысленно до исправления, по 5xx повторять можно и нужно, с задержкой.

Дальше покажите, как это ложится в спецификацию метода. Перечисляются все возможные ответы: 200 с телом, 201 с идентификатором созданного объекта, 204 на удаление, 400 на нарушение формата, 401 на отсутствующий или истёкший токен, 403 на нехватку прав, 404 на несуществующий объект, 409 на конфликт состояния (повторная оплата, занятый логин), 422 на семантически неверные данные, 429 на превышение лимита, 503 на плановую недоступность. У каждой ошибки свой машиночитаемый код и текст для пользователя.

Отдельно проговорите разницу транспортной и бизнесовой ошибки: отказ в услуге по правилам это успешный ответ с решением внутри, а не 400.

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

Описывают только счастливый путь. Матрицу ошибок дописывают уже во время интеграции, по переписке, и она навсегда расходится с документацией.

Смешивают 401 и 403 в одну строку про отсутствие доступа. Тестировщик не может проверить такую формулировку, а фронтенд не понимает, вести пользователя на форму входа или показывать заглушку про права.

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