Зачем это спрашивают
Код ответа — первое, что тестировщик видит в Network или Postman. По нему вы решаете, чей это дефект и насколько он серьёзен: 4xx обычно говорит о проблеме в запросе, 5xx — о сбое на сервере. Интервьюер хочет услышать, что вы различаете группы, знаете смысл частых кодов и не путаете близкие по смыслу пары.
Пара 401 и 403 — классическая проверка на понимание разницы между аутентификацией и авторизацией. Кандидат, который здесь уверен, обычно хорошо проверяет права доступа, а это одна из самых чувствительных областей любого продукта.
Как построить сильный ответ
Начните с групп, затем назовите частые коды, затем ответьте на вторую часть вопроса.
Пять групп
- 1xx — информационные: сервер принял начало запроса, работа продолжается. Пример — 101 Switching Protocols при переходе на WebSocket.
- 2xx — успех.
- 3xx — перенаправление: нужное лежит в другом месте или у клиента уже есть актуальная копия.
- 4xx — ошибка на стороне клиента: запрос неправильный, неполный или не разрешён.
- 5xx — ошибка на стороне сервера: запрос мог быть корректным, но сервер не справился.
Коды, которые стоит знать одной фразой
| Код | Смысл |
|---|---|
| 200 OK | запрос выполнен, результат в теле |
| 201 Created | ресурс создан, адрес часто в заголовке Location |
| 204 No Content | успех, тела нет — типично для DELETE |
| 301 / 308 | ресурс переехал навсегда; 308 сохраняет метод |
| 302 / 307 | временное перенаправление; 307 сохраняет метод |
| 304 Not Modified | у клиента актуальная копия, можно взять из кэша |
| 400 Bad Request | запрос некорректен: битый JSON, неверный формат |
| 401 Unauthorized | клиент не аутентифицирован |
| 403 Forbidden | клиент известен, но доступа нет |
| 404 Not Found | ресурс не найден |
| 405 Method Not Allowed | метод не поддерживается для этого адреса |
| 409 Conflict | конфликт с текущим состоянием, например дубль |
| 422 Unprocessable Content | формат верный, но данные не прошли проверку |
| 429 Too Many Requests | превышен лимит запросов |
| 500 Internal Server Error | необработанная ошибка на сервере |
| 502 Bad Gateway | прокси получил неверный ответ от сервера за ним |
| 503 Service Unavailable | сервис временно недоступен |
| 504 Gateway Timeout | прокси не дождался ответа от сервера за ним |
401 против 403
Название 401 Unauthorized исторически неудачное: на деле речь об аутентификации. Сервер говорит «я не знаю, кто вы»: токена нет, он истёк или подделан. По RFC 9110 такой ответ должен содержать заголовок WWW-Authenticate, подсказывающий, как пройти аутентификацию. Правильная реакция клиента — войти заново или обновить токен.
403 Forbidden означает «я понял запрос, но выполнять его не буду». Обычно пользователь уже вошёл, но его роли не хватает прав. Повторный вход не поможет — нужны другие права.
GET /api/users/me HTTP/1.1
→ 401 Unauthorized (запрос без токена)
GET /api/reports/finance HTTP/1.1
Authorization: Bearer <токен сотрудника без доступа к отчётам>
→ 403 Forbidden (роли не хватает прав)
Пример ответа
Коды делятся на пять групп: 1xx — информационные, 2xx — успех, 3xx — перенаправления, 4xx — ошибка клиента, 5xx — ошибка сервера. Чаще всего встречаю 200, 201 при создании и 204 при удалении; из 3xx — 301, 302 и 304 для кэша; из 4xx — 400, 401, 403, 404, 409, 422 и 429; из 5xx — 500, 502, 503 и 504. 401 значит, что сервер не знает, кто я: нет токена или он истёк. 403 — сервер меня узнал, но прав не хватает. Например, открыть профиль без входа — это 401, а зайти покупателем в админку заказов — 403. Для меня важно и то, что 5xx в ответ на некорректные данные — всегда баг: сервер должен вернуть понятную 4xx.
Частые ошибки
- Знать только 200, 404 и 500 и не уметь объяснить, что означает группа целиком.
- Считать 401 и 403 синонимами или менять их местами.
- Считать нормой 500 на невалидный ввод. Падение сервера от неверного запроса — дефект, даже если ошибка «ожидаемая».
- Не смотреть на тело ошибки. Правильный код без понятного сообщения тоже стоит обсудить с командой.
- Путать 502 и 504: в первом случае прокси получил плохой ответ, во втором — не дождался никакого.
Пример на MarketCove
Как бы вы проверяли коды ответа в API учебного магазина MarketCove:
- Без входа. Запросите
GET /api/users/meбез заголовка авторизации, затем с испорченным токеном. Ожидаете 401 в обоих случаях и понятное сообщение, а не 500. - Чужой заказ. Создайте два аккаунта, оформите заказ под первым и запросите
GET /api/orders/{id}с токеном второго. Какой код правильный — 403 или 404, — вопрос к контракту: посмотрите, что сказано в Swagger на/api/docs, и вспомните, почему 404 иногда выбирают намеренно. - Несуществующий товар.
GET /api/products/{id}с несуществующим id должен дать 404, а id в виде строкиabc— 400 или 404 по контракту, но не 500. - Создание заказа. Успешное оформление через
/api/shop/orders— 200 или 201; проверьте, что заказ действительно появился в истории. Тело без обязательного поля или с несуществующим товаром — 4xx с понятным текстом, а не 500.
Если код кажется неправильным, сначала откройте DevTools: иногда ошибку показывает интерфейс, а сервер ответил корректно. Как отличить такие случаи, разобрано в статье о багах на фронтенде и бэкенде.
Задание для практики
Возьмите пять эндпоинтов из Swagger магазина и для каждого выпишите минимум три ожидаемых кода с условиями: успех, ошибка клиента, нет прав. Затем проверьте каждый в API-песочнице или Postman и отметьте расхождения. Отдельно потренируйтесь объяснять разницу 401 и 403 за 30 секунд на примере любого знакомого сервиса — именно в таком формате вопрос обычно и звучит.
