Что означают HTTP статусы 100, 400, 401, 404 и на какой стороне ошибка

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

Знаете ли вы классы статусов и умеете ли по коду определить, куда идти с багом: к бэкенду, к фронтенду или к тому, кто настраивал маршрутизацию. Для тестировщика это ежедневный навык.

Как отвечать

Сначала классы: 1xx информационные, 2xx успех, 3xx перенаправление, 4xx ошибка на стороне клиента, 5xx ошибка на стороне сервера. Затем по каждому коду из вопроса:

• 100 Continue: не ошибка, а служебный ответ. Клиент отправил заголовок Expect: 100-continue, спрашивая, стоит ли слать тело, сервер отвечает «продолжай». Экономит трафик при больших загрузках, если сервер собирался отклонить запрос;
• 400 Bad Request: сервер не смог разобрать запрос. Битый JSON, отсутствующий обязательный параметр, неверный тип значения. Сторона клиента, чинится в запросе;
• 401 Unauthorized: не хватает аутентификации, то есть система не знает, кто вы: токена нет, он просрочен или неверен. Рядом обязательно назовите 403 Forbidden: там система вас узнала, но доступ к ресурсу запрещён;
• 404 Not Found: ресурса по этому адресу нет. Формально это класс клиента, на практике причина часто на стороне сервера: не поднялся маршрут, ошибка в конфигурации, объект удалён, а ссылка осталась. Поэтому в баг-репорте по 404 полезно приложить точный URL и ответ сервера.

Для тестировщика важен вывод: 4xx это повод проверить сам запрос (тело, заголовки, права, адрес), 5xx это дефект на сервере, который заводится сразу.

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

Путают 401 и 403.

Считают любой 4xx виной фронтенда. Если API документирует поле, а сервер его не принимает, дефект серверный, независимо от кода.

Не замечают, что API отдаёт 200 с текстом ошибки внутри тела. Это отдельный дефект: код ответа обязан отражать результат.