Код ответа это первое, что проверяет любой API-тест, и первое, что спрашивают на собесе. Задача не выучить все коды, а понимать классы и уверенно различать два десятка частых.
Классы
- 1xx информационные (например
101 Switching Protocolsпри переходе на WebSocket). - 2xx успех.
- 3xx перенаправление.
- 4xx ошибка клиента: запрос неверен или этому клиенту нельзя.
- 5xx ошибка сервера.
Для баг-репорта это главное различие: на 4xx сначала проверь свой запрос, на 5xx почти всегда виноват бэкенд.
Успех
200 OKуниверсальный успех.201 Createdресурс создан, адрес в заголовкеLocation.202 Acceptedпринято в обработку, но ещё не сделано (асинхронная задача).204 No Contentуспех без тела. Тело у 204 это нарушение стандарта.
Перенаправления
301и308перенесено навсегда,302и307временно.- Разница пар: при
307и308клиент обязан повторить тот же метод с тем же телом. При301и302клиенты исторически превращают POST в GET, и тело теряется. 303 See Otherпрямо говорит «иди GET-ом», его отдают после отправки формы.304 Not Modifiedответ на условный запрос: ресурс не менялся, бери из кеша.
Ошибки клиента
| Код | Когда |
|---|---|
| 400 Bad Request | битый JSON, неверный тип, нет обязательного поля |
| 401 Unauthorized | нет токена, он неверен или просрочен; с заголовком WWW-Authenticate |
| 403 Forbidden | личность известна, но прав нет |
| 404 Not Found | ресурса нет (или его существование намеренно скрыто) |
| 405 Method Not Allowed | метод не поддерживается; обязателен заголовок Allow |
| 409 Conflict | конфликт с состоянием: дубль email, устаревшая версия |
| 415 Unsupported Media Type | неверный Content-Type тела |
| 422 Unprocessable Content | JSON верный, но данные не проходят правила |
| 429 Too Many Requests | превышен лимит; подсказка в Retry-After |
Пара 401 и 403 самая частая на собесе. Название «Unauthorized» сбивает: по смыслу 401 это «не аутентифицирован», а 403 «не авторизован».
Пара 400 и 422: одни API отдают 400 на любую ошибку данных, другие разделяют синтаксис (400) и смысл (422). Оба подхода нормальны, ошибка это смешивать их случайным образом.
Ошибки сервера
500 Internal Server Errorнеобработанное исключение в приложении.502 Bad Gatewayпрокси (nginx, балансировщик) получил от бэкенда мусор или не смог соединиться: сервис упал или перезапускается.503 Service Unavailableсервис временно не может обслуживать: перегрузка, обслуживание.504 Gateway Timeoutпрокси не дождался ответа бэкенда.
502 и 504 обычно отдаёт не ваше приложение, а прокси перед ним. Это подсказка, в чьих логах искать.
Правило тестировщика
Любой 5xx на некорректный ввод это баг. Сервер обязан поймать мусор и ответить 4xx с понятным сообщением. 500 в ответ на строку вместо числа значит, что валидации нет, и иногда в ответ вываливается стектрейс с путями и SQL.
Второе правило: код должен быть честным. API, которое на всё отвечает 200 и пишет "success": false в теле, ломает мониторинг, ретраи и кеши. Исключение по соглашению: GraphQL, где ошибки в теле при 200 обычная практика.
Частые ошибки
- Проверять только код и не смотреть тело и заголовки.
- Считать 404 на второй DELETE нарушением идемпотентности.
- Путать 502 и 504 в баг-репорте: причины и место поиска разные.
- Не проверять заголовки, которые стандарт связывает с кодом:
Location,Allow,WWW-Authenticate,Retry-After.
Что спросят на собесе
- Назовите классы кодов и примеры из каждого.
- Чем 401 отличается от 403?
- Что вернуть при создании ресурса, при удалении, при дубле?
- Чем 502 отличается от 504 и где искать причину?
- Всегда ли 500 означает баг?