Модуль 12

HTTP status codes і обробка помилок

Ось готовий урок, згенерований за твоїм майстер-промптом. Це класичний CS50-вайб: енергійно, зрозуміло і з фокусом на те, як це працює насправді.

🎓 Тема: HTTP Status Codes і Обробка Помилок

(або "Як сервер каже вам: 'Це не я, це ти'")

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви прийшли до ресторану. Ви відкриваєте меню, тицяєте пальцем у страву "Лобстер по-королівськи" і кажете офіціанту: "Хочу це". Офіціант киває і йде на кухню.

Ви чекаєте 20 хвилин. Офіціант повертається, ставить перед вами порожню тарілку і мовчки йде. Що це означає? * Лобстери закінчилися? * Кухар захворів? * Ви забули заплатити за вхід? * Чи, може, ресторан переїхав, а ви сидите в закинутій будівлі?

Без пояснень ви розгублені. Ви не знаєте, що робити далі: чекати, кричати чи йти в інше місце.

В інтернеті — те саме. Ваш браузер (клієнт) постійно щось просить у сервера. Якби сервер просто мовчав або надсилав порожню сторінку при помилці, програми б не працювали.

HTTP статус-коди — це і є той самий офіціант, який повертається і каже коротку фразу: "Успіх", "Не знайдено" або "Я зламався". Без цього діалогу інтернет був би хаосом.

2. 🧠 Теоретична база (без сухої академічності)

Коли ви надсилаєте запит (Request), сервер завжди повертає тризначне число. Це і є Status Code.

Давайте заглянемо "під капот". Це число прилітає в заголовку (Header) відповіді раніше, ніж картинки чи текст сайту. Браузер бачить число і миттєво розуміє: малювати сайт чи показувати помилку.

Вам не треба зубрити всі коди (їх більше 60!), але треба зрозуміти логіку першої цифри. Це як поверхи в будівлі:

🟢 2xx — Успіх ("Все добре, ось твоє замовлення")

  • 200 OK: Класика. Ви просили — ми дали.
  • 201 Created: Ви щось створили (наприклад, зареєструвалися), і сервер каже: "Записав, готово".

🟡 3xx — Перенаправлення ("Тобі не сюди, йди в інше вікно")

  • 301 Moved Permanently: Сайт переїхав назавжди. Google запам'ятає нову адресу.
  • 302 Found (Temporary Redirect): Ми поки тут ремонт робимо, тимчасово йди туди.

🟠 4xx — Помилка Клієнта ("Ти помилився")

Це найважливіша частина для нас. Це означає: сервер працює, але ти (браузер/користувач) просиш дурницю.

  • 400 Bad Request: Сервер каже: "Я не розумію, що ти написав". (Кривий синтаксис).
  • 401 Unauthorized: "Хто ти такий?". Потрібен логін і пароль.
  • 403 Forbidden: "Я знаю, хто ти, але тобі сюди не можна". (Наприклад, звичайний юзер лізе в адмінку).
  • 404 Not Found: Класика. "Такої сторінки не існує".

🔴 5xx — Помилка Сервера ("Я помилився")

Це означає: ти все зробив правильно, але сервер "впав".

  • 500 Internal Server Error: Загальна помилка. На сервері в коді стався вибух (exception).
  • 503 Service Unavailable: Сервер перевантажений або на техобслуговуванні. "Передзвоніть пізніше".

Інтуїтивно: * 2xx — 👍 (Круто) * 4xx — 🫵 (Ти винен) * 5xx — 🤕 (Я [сервер] хворію)

3. 🧪 Приклади (від простого до реального)

Приклад 1: Звичайний серфінг

Ви вводите google.com. Питання до вас: Який код поверне сервер Google, коли покаже рядок пошуку? (Подумайте секунду...)

Відповідь: 200 OK. Все штатно.

Приклад 2: "Розумний" логін

Уявіть, ви пишете код для входу на сайт. Користувач вводить правильний логін, але неправильний пароль.

Питання: Що має відповісти сервер? а) 200 OK (і написати текстом "Пароль невірний") б) 404 Not Found в) 401 Unauthorized

Правильна відповідь: 401 Unauthorized. Чому не 200? Бо 200 означає "операція успішна". А вхід не відбувся. Якщо ви повернете 200, браузер може запропонувати зберегти цей "невірний" пароль. Логіка ламається.

Приклад 3: Реальний кейс (API)

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

Сервер (Backend) перевіряє дані, бачить, що адреси немає. Він повертає: * Status: 400 Bad Request * Body: {"error": "Address is required"}

Чому це круто? Ваша програма бачить код 400 і одразу підсвічує поле адреси червоним. Їй навіть не треба читати текст помилки, щоб зрозуміти, що щось не так із даними.

4. 🛠 Практична частина

Спробуйте вирішити ці ситуації. Як би ви налаштували відповідь сервера?

Завдання 1: Знайди шпигуна Користувач намагається видалити коментар іншого користувача. Він залогінений, але у нього немає прав адміністратора. * Який код повернути: 401 чи 403? Чому?

Завдання 2: Привид Ви звертаєтесь до бази даних за товаром id=9999, але такого товару немає. * Що повернути: 200 (з порожнім тілом), 400 чи 404?

Завдання 3: Апокаліпсис Ваш код на Python поділив на нуль, і все впало. * Який код автоматично полетить клієнту? (500 чи 503?)

Завдання 4: Міні-кейс Ви робите форму реєстрації. Користувач натиснув "Зареєструватися", все пройшло добре. * Чи достатньо повернути 200 OK? Чи є більш точний код для створення ресурсу?

5. 💡 Мислення як у розробника

Ось де новачки "паляться", а профі — ні.

❌ Типова помилка новачка: "Синдром 200"

Новачки часто роблять так: сервер завжди повертає 200 OK, навіть якщо сталася помилка. А про помилку пишуть у JSON:

HTTP/1.1 200 OK
{
  "status": "error",
  "message": "Database crashed"
}

Чому це жахливо? Тому що системи моніторингу та браузери дивляться на заголовки. Вони думають: "О, 200! Все працює чудово!", хоча насправді у вас все горить. Ви не дізнаєтесь про проблему, поки користувачі не почнуть дзвонити в підтримку.

✅ Як думає профі:

  1. Розділяй відповідальність. Якщо клієнт надіслав криві дані — це його проблема (4xx). Не засмічуй свої логи помилками сервера (5xx) через те, що хтось забув ввести email.
  2. Безпека через неоднозначність. Іноді, коли вводять неправильний логін, краще повернути 401, але написати "Невірний логін або пароль". Не підказуйте хакерам, що саме вони вгадали (логін), а що ні (пароль).

6. 🧩 Підсумок

Отже, що ми маємо сьогодні в сухому залишку:

  1. HTTP-коди — це мова емоцій сервера.
  2. 2xx — все добре.
  3. 4xx — помилка клієнта (виправляй запит).
  4. 5xx — помилка сервера (виправляй бекенд).
  5. Ніколи не брешіть кодом 200, якщо щось пішло не так.

Тепер ви вмієте не просто "надсилати дані", а вести діалог із системою.

🚀 Що далі? Гаразд, ми навчилися стукати у двері і розуміти, чи нам раді. Але як передати через ці двері складну посилку, а не просто текст? На наступному уроці розберемо JSON та структуру API-запитів. Це буде цікаво!

(Завіса. David Malan вимикає клікер і йде зі сцени під оплески)

← До списку уроків Наступний урок →