HTTP статус коды

HTTP Статус коды: Ошибки клиента (4xx)

📚 24 вопросовПройти тест →
Лекция

HTTP Статус коды: Ошибки клиента (4xx)

HTTP статус коды

Статус коды: ошибки клиента (4xx)

Введение: красный сигнал 🚫

4xx — это «ошибка со стороны клиента».
Сервер говорит: «Я понял, что ты хочешь, но запрос неправильный».
💡 Совет: правильный 4xx помогает клиенту быстро исправить запрос.
✅ Вывод: 4xx = «проблема в запросе, а не в сервере».

Проблема → решение

Проблема: если отдавать 200/500 вместо 4xx, клиент теряется и делает хуже.
Решение: использовать точные коды для каждой ситуации.
✅ Вывод: 4xx — это подсказка для клиента.

Чем помогает и как работает

4xx‑коды показывают, что запрос сформирован неправильно или доступ запрещён. Клиент сразу понимает, что нужно исправить.
Как это работает:
  1. Сервер валидирует запрос, права и параметры.
  2. При ошибке выбирает нужный код (400/401/403/404/409/422/429).
  3. Клиент исправляет данные или проходит авторизацию.
✅ Вывод: 4xx помогают быстро диагностировать ошибки клиента.

Ключевые термины (простыми словами)

  • 4xx — ошибки клиента.
  • Validation (валидация) — проверка данных.
  • Auth (аутентификация) — проверка «кто ты».
  • Authorization (авторизация) — проверка «что тебе можно».
  • Rate limit — ограничение частоты запросов.
✅ Вывод: важно различать типы ошибок.

Самое важное (must‑know)

  • 401 = нет авторизации, и нужен заголовок WWW‑Authenticate.
  • 403 = доступ запрещён, даже если пользователь залогинен.
  • 400 vs 422: 400 — синтаксис сломан, 422 — данные не прошли валидацию.
  • 429 = слишком часто, и нужен Retry-After.
  • Content-Type не подходит → 415 Unsupported Media Type (частая ошибка новичков).
✅ Вывод: эти различия обязательно должен знать каждый разработчик API.

1. 400 Bad Request — запрос неправильный

Назначение: синтаксическая ошибка в запросе.
Простыми словами: запрос «кривой» и сервер не смог его разобрать.
Аналогия: вы написали адрес с ошибкой.
Пример:
HTTP/1.1 400 Bad Request
🔎 Как это происходит на практике:
  1. Клиент отправляет сломанный JSON или без обязательного поля.
  2. Сервер не может разобрать запрос.
  3. Ответ — 400 Bad Request с описанием ошибки.
Когда использовать: неверный JSON, обязательное поле отсутствует.
✅ Вывод: 400 = «сломана форма запроса».

2. 401 Unauthorized — не авторизован

Назначение: нет или неверный токен.
Простыми словами: сначала нужно пройти авторизацию.
Аналогия: пришли без пропуска.
Пример:
HTTP/1.1 401 UnauthorizedWWW-Authenticate: Bearer
Важно: заголовок WWW-Authenticate обязателен — он подсказывает, как авторизоваться.
🔎 Как это происходит на практике:
  1. Клиент обращается к защищённому ресурсу без токена.
  2. Сервер отвечает 401 Unauthorized и WWW-Authenticate.
  3. Клиент должен авторизоваться и повторить запрос.
Когда использовать: нет токена или он истёк.
✅ Вывод: 401 = «сначала авторизуйся».

3. 403 Forbidden — доступ запрещён

Назначение: вы авторизованы, но доступа нет.
Простыми словами: вы залогинены, но это действие запрещено.
Аналогия: пропуск есть, но не в эту комнату.
Пример:
HTTP/1.1 403 Forbidden
🔎 Как это происходит на практике:
  1. Клиент авторизован, но роль не даёт доступ.
  2. Сервер проверяет права и запрещает действие.
  3. Ответ — 403 Forbidden.
Когда использовать: роль не позволяет действие.
✅ Вывод: 403 = «ты не можешь это делать».

4. 404 Not Found — ресурс не найден

Назначение: ресурс не существует.
Простыми словами: сервер не нашёл то, что вы запросили.
Аналогия: такого дома нет.
Пример:
HTTP/1.1 404 Not Found
🔎 Как это происходит на практике:
  1. Клиент запрашивает /courses/9999, которого нет.
  2. Сервер не находит ресурс.
  3. Ответ — 404 Not Found.
Когда использовать: неправильный ID, путь не существует.
✅ Вывод: 404 = «ресурс не найден».

5. 409 Conflict — конфликт данных

Назначение: запрос конфликтует с текущим состоянием.
Простыми словами: действие невозможно из‑за конфликта (дубликат/гонка).
Аналогия: пытаетесь забронировать уже занятое место.
Пример:
HTTP/1.1 409 Conflict
🔎 Как это происходит на практике:
  1. Клиент пытается создать ресурс с уже существующим уникальным значением.
  2. Сервер фиксирует конфликт состояния.
  3. Ответ — 409 Conflict.
Когда использовать: дубликат, гонка, конфликт версии.
✅ Вывод: 409 = «конфликт».

6. 422 Unprocessable Entity — данные не проходят валидацию

Назначение: синтаксис ок, но данные неверны.
Простыми словами: формат правильный, но значения не прошли проверку.
Аналогия: адрес написан правильно, но такого дома нет.
Пример:
HTTP/1.1 422 Unprocessable Entity
🔎 Как это происходит на практике:
  1. Формат запроса корректный, но значения невалидны.
  2. Сервер возвращает список ошибок.
  3. Ответ — 422 Unprocessable Entity.
Когда использовать: неверный email, короткий пароль.
✅ Вывод: 422 = «данные невалидны».

7. 429 Too Many Requests — слишком много запросов

Назначение: превышен лимит.
Простыми словами: слишком много запросов за короткое время.
Аналогия: вы слишком часто звоните.
Пример:
HTTP/1.1 429 Too Many RequestsRetry-After: 60
🔎 Как это происходит на практике:
  1. Клиент отправляет слишком много запросов за короткое время.
  2. Сервер срабатывает на rate limit.
  3. Ответ — 429 Too Many Requests + Retry-After.
Когда использовать: rate limit. Retry-After обязателен.
✅ Вывод: 429 = «подожди».

Таблица 4xx

КодСмыслКогда использовать
400плохой запроссинтаксис, JSON сломан
401не авторизованнет/истёк токен
403запрещенонет прав
404не найденресурс отсутствует
409конфликтдубликаты/гонки
422невалидные данныеошибки в полях
429лимит превышенrate limit

Часто спрашивают на собеседованиях

  • 401 vs 403? 401 — нет логина, 403 — прав нет.
  • 400 vs 422? 400 — запрос сломан, 422 — данные невалидны.
  • Когда 409? конфликт состояния (дубликат, гонка).
  • Что такое rate limit? ограничение частоты, код 429.
  • Зачем WWW-Authenticate? подсказывает, как авторизоваться при 401.
  • Когда нужен 415? когда Content-Type не поддерживается сервером.
✅ Вывод: это самые частые вопросы по 4xx.

Типичные ошибки

Ошибка 1: 500 вместо 4xx

❌ отдаём 500 на ошибку клиента
✅ отдаём 4xx
Почему: сервер не виноват.

Ошибка 2: 401 вместо 403

❌ нет прав, но отдаём 401
✅ правильный 403
Почему: важно различать.

Ошибка 3: 400 вместо 422

❌ валидация данных через 400
✅ 422 для ошибок полей
Почему: 400 — про синтаксис.

Best Practices

  • Делайте понятное сообщение об ошибке.
  • Различайте 401 и 403.
  • Используйте 422 для ошибок валидации.
  • Возвращайте 409 при конфликте.
  • Добавляйте WWW-Authenticate в 401.
  • Добавляйте Retry-After в 429.
  • Для неверного Content-Type используйте 415.

Заключение

🎯 4xx — это ошибки запроса клиента.
🎯 Точный код = понятный диагноз.
🎯 Чем лучше 4xx, тем меньше поддержки.
Теперь вы знаете, как «говорить» клиенту, что он сделал не так.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «HTTP Статус коды: Ошибки клиента (4xx)»

Пройти тест →