Які HTTP статус коди ви знаєте?

Junior Level

HTTP статус-коди — це тризначні числа, які сервер повертає клієнту, щоб повідомити про результат запиту.

Перша цифра — категорія: 2 = все добре, 4 = проблема на вашому боці (клієнт), 5 = проблема на нашому боці (сервер). Це допомагає автоматично обробляти помилки.

Класи статус-кодів:

Клас	Діапазон	Значення
1xx	100-199	Інформаційні
2xx	200-299	Успіх
3xx	300-399	Перенаправлення
4xx	400-499	Помилка клієнта
5xx	500-599	Помилка сервера

Найпоширеніші коди:

Код	Назва	Опис
200	OK	Запит виконано успішно
201	Created	Ресурс створено
204	No Content	Успіх, без тіла відповіді
301	Moved Permanently	Ресурс переміщено назавжди
302	Found	Тимчасове перенаправлення
400	Bad Request	Некоректний запит
401	Unauthorized	Не авторизований (потрібен логін)
403	Forbidden	Заборонено (немає прав)
404	Not Found	Не знайдено
500	Internal Server Error	Внутрішня помилка сервера
503	Service Unavailable	Сервіс недоступний

Middle Level

2xx: Success

201 Created: Повертайте із заголовком Location
202 Accepted: Для систем на основі черг. “Я прийняв завдання, ID такий-то, результат буде пізніше”
204 No Content: Ідеально для DELETE і PUT. Економить трафік — тіло відповіді відсутнє

3xx: Redirection

304 Not Modified: Ключ до продуктивності. Використовується при Conditional GET (з If-None-Match). Сервер не надсилає тіло
307 Temporary Redirect / 308 Permanent Redirect: На відміну від 301/302, ці коди гарантують, що HTTP-метод не зміниться (POST залишиться POST)

// 301/302 історично дозволяли браузеру змінювати POST на GET при редиректі.
// 307/308 введені, щоб строго зберегти метод — критично для REST API.

4xx: Client Error

401 vs 403: 401 — немає аутентифікації (Identity unknown), 403 — немає прав (Identity known, but access denied)
409 Conflict: При порушенні бізнес-логіки (дублікат email) або конфлікті версій в Optimistic Locking
422 Unprocessable Entity: Стандарт для помилок валідації (RFC 4918)

400 = “я не зрозумів ваш запит” (синтаксична помилка, malformed JSON). 422 = “я зрозумів запит, але дані не проходять валідацію” (email без @, пароль < 8 символів). Клієнт за кодом розуміє: треба виправити дані, а не формат запиту.

429 Too Many Requests: Сигнал від Rate Limiter. Завжди додавайте заголовок Retry-After

5xx: Server Error

502 Bad Gateway: Проблема “сусіда”. Nginx не зміг достукатися до Java-додатку
503 Service Unavailable: Сервер перевантажений або на обслуговуванні. Балансувальники повинні виключити вузол з ротації
504 Gateway Timeout: Бекенд (Java) не відповів вчасно проксі-серверу (Nginx)

Діагностика

Golden Signals: Error Rate — один із чотирьох золотих сигналів моніторингу (SRE)
Log Correlation: Кожна помилка повинна містити Trace-ID
HTTP 500 у Java: Як правило, не повертайте 500 вручну — нехай фреймворк робить це для необроблених винятків. 500 має означати “щось пішло не так”, а не “бізнес-логіка заборонила”.

Senior Level

RFC 7807 (Problem Details)

Сучасні API (включаючи Spring Boot 3+) переходять від простих кодів до структурованих помилок за RFC 7807 (RFC 9457 замінив RFC 7807 у 2023):

{
  "type": "https://example.com/probs/out-of-stock",
  "title": "Out of Stock",
  "status": 400,
  "detail": "Item ID 123 is no longer available",
  "instance": "/orders/456"
}

// type — URI з документацією помилки (машиночитаемий)
// title — короткий опис для розробника
// status — дублює HTTP код
// detail — людиночитабельне пояснення
// instance — URI конкретного запиту (для логів)

Highload і балансування

У високонавантажених системах правильний код відповіді критичний для роботи балансувальників (L7 Load Balancers), які на основі цих кодів приймають рішення про “здоров’я” (Health Check) сервісу.

Negative Caching

CDN (наприклад, Cloudflare) можуть кешувати відповіді 404 або 500, щоб захистити бекенд від “шторму запитів” до неіснуючих ресурсів.

Circuit Breaker

Якщо мікросервіс починає сипати 5xx кодами, вищестоящий сервіс має спрацювати за патерном Circuit Breaker, щоб не “добити” умираючий інстанс.

Ієрархія і Senior-нюанси

307/308 гарантують збереження методу, на відміну від 301/302 (можуть змінити POST на GET)
422 переважніший за 400 для помилок валідації — більш семантичний
429 завжди має супроводжуватися Retry-After для коректної поведінки клієнтів
500 — це завжди баг додатку, а не бізнес-помилка. Для передбачуваних помилок бізнесу використовуйте 4xx

Моніторинг

Помилки (Error Rate) — один із чотирьох золотих сигналів SRE
Кожна помилка повинна містити Trace-ID для відновлення ланцюжка викликів
Відстежуйте гістограми затримок (P99) у розрізі методів (GET vs POST)

🎯 Шпаргалка для співбесіди

Обов’язково знати:

5 класів статус-кодів: 1xx (інформаційні), 2xx (успіх), 3xx (редирект), 4xx (помилка клієнта), 5xx (помилка сервера)
200 OK, 201 Created (із заголовком Location), 202 Accepted (для асинхронних завдань), 204 No Content (для DELETE/PUT)
301/302 можуть змінювати POST на GET; 307/308 гарантують збереження методу
400 = «я не зрозумів запит» (malformed JSON), 422 = «дані не проходять валідацію»
401 = не аутентифікований (хто ви?), 403 = немає прав (знаю, але не можна)
409 Conflict — дублікат або конфлікт версій; 429 Too Many Requests — rate limit
500 = баг додатку, 502 = бекенд не відповідає, 503 = перевантажений/обслуговування, 504 = тайм-аут бекенда
RFC 9457 (Problem Details) — стандартний JSON для помилок: type, title, status, detail, instance

Часті уточнюючі запитання:

Коли використовувати 422 замість 400? — 422 для помилок валідації даних, 400 для синтаксичних помилок запиту
Чому 307/308 важливіші за 301/302 для REST API? — 307/308 зберігають HTTP-метод при редиректі
Навіщо потрібен 202 Accepted? — Для асинхронних завдань: «прийняв, оброблю пізніше»
Чому 500 — це завжди баг? — 500 означає непередбачену помилку; бізнес-помилки мають бути 4xx

Червоні прапорці (НЕ говорити):

«400 і 422 — одне й те саме» — 400 = malformed запит, 422 = дані невалідні
«301/302 зберігають метод при редиректі» — вони можуть змінювати POST на GET, 307/308 — ні
«500 — нормальна відповідь для бізнес-помилок» — бізнес-помилки = 4xx, 500 = непередбачений баг
«401 і 403 — одне й те саме» — 401 = не знаю хто ви, 403 = знаю, але немає прав

Пов’язані теми:

[[В чому різниця між 401 та 403]]
[[Що таке REST]]
[[Що таке RESTful API дизайн]]
[[Як правильно іменувати REST endpoints]]
[[Що таке Accept header]]