Какие группы кодов ответа от сервера существуют

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

Знание классов HTTP-кодов и, главное, умение превратить их в поведение интерфейса: что увидит пользователь при 401, 422 или 503. Следом часто спрашивают, почему fetch не упал на ответе с ошибкой.

Как отвечать

Коротко про пять групп, первая цифра задаёт смысл:

• 1xx: служебные, из JavaScript их почти не видно. 101 Switching Protocols встречается при открытии WebSocket;
• 2xx: успех. 200, 201 после создания, 204 без тела;
• 3xx: перенаправления и кэш. 301 и 308 постоянные, 302 и 307 временные, 304 Not Modified приходит на условный запрос, и браузер берёт тело из своего кэша;
• 4xx: ошибка клиента. 400, 401 нужна авторизация, 403 нет прав, 404, 409, 422 ошибки валидации, 429 слишком много запросов;
• 5xx: сбой сервера или шлюза. 500, 502, 503, 504.

Главное для фронтенда: fetch отклоняет промис только при сетевой ошибке или блокировке CORS, а ответ 404 или 500 приходит как обычный, поэтому проверяют response.ok, он истинен для кодов от 200 до 299. Axios по умолчанию, наоборот, бросает исключение на всё вне 2xx. На 204 вызов response.json() упадёт, тела нет.

Дальше разложите реакцию по кодам:

• 401: попытка обновить токен, при неудаче переход на вход;
• 403: сообщение о нехватке прав, а не редирект на логин;
• 422: ошибки из тела ответа привязать к полям формы;
• 429 и 503: повтор с паузой по заголовку Retry-After;
• 5xx на GET: повторный запрос. TanStack Query по умолчанию повторяет упавший запрос три раза с растущей задержкой.

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

Думают, что fetch бросит исключение на 500, и не проверяют response.ok. Интерфейс пытается отрисовать тело ошибки как данные.

Путают 401 и 403 и отправляют пользователя без нужных прав на страницу входа, откуда он возвращается туда же.

Повторяют неидемпотентные запросы. Автоматический повтор POST после 504 может создать заказ дважды, если сервер его всё-таки обработал.