HTTP статус-коди

Що таке HTTP статус-код і на які класи поділяються коди?

Статус-код — трицифрове число в першому рядку відповіді сервера, яке повідомляє долю запиту: чи опрацьовано його, а якщо ні — на чиєму боці проблема. Коди поділені на пʼять класів за першою цифрою: 1xx — інформаційні проміжні сигнали, 2xx — успіх, 3xx — перенаправлення (потрібен ще один крок), 4xx — помилка клієнта, 5xx — помилка сервера. Перша цифра — не косметика: вона одразу задає стратегію реакції. Побачив 4xx — виправляй запит; побачив 5xx — запит нормальний, зламався сервер. Для AQA це базовий інструмент діагностики: розбір будь-якого червоного тесту чи «нічого не працює на стейджі» починається з питання «а який код повернув сервер?».

У чому принципова різниця між 4xx і 5xx?

Різниця у «власнику» проблеми: 4xx — «ти (клієнт) зробив щось не так», 5xx — «я (сервер) не впорався». При 4xx сервер зрозумів запит і свідомо відмовив, бо із самим запитом щось не так — виправляти треба запит, дані або права клієнта. При 5xx запит був нормальний, а зламався сервер: неопрацьований виняток, перевантаження, проблеми на проксі. Ця межа — головний орієнтир, коли зʼясовуєш, у чиєму коді баг. У тестуванні вона визначає, куди заводити дефект: 4xx на валідному запиті — питання до клієнта чи самого тесту, 5xx — майже завжди щонайменше одна проблема на бекенді, бо добре спроєктований сервер навіть на сміття має відповідати 400/422, а не падати.

Чим відрізняються 200, 201 і 204?

Це три різновиди успіху. 200 OK — універсальний успіх з результатом у тілі, найчастіше відповідь на GET. 201 Created каже більше: створено новий ресурс; за домовленістю сервер додає заголовок Location з адресою нового ресурсу, а часто і його представлення в тілі — типова відповідь на POST. 204 No Content — успіх без тіла: класика для DELETE, який видалив запис, або PUT, коли повертати нема чого. Для автотестів різниця практична: асерт expect(res.status).toBe(200) почервоніє, якщо ендпоінт після рефакторингу почав чесно повертати 201, хоча функціонал працює. І навпаки — 200 замість 201 на створенні може бути легітимною претензією до API-контракту. Ще типова пастка: await res.json() після 204 падає з помилкою парсингу, бо тіла там і не мало бути.

У чому різниця між 401 Unauthorized і 403 Forbidden?

401 відповідає на питання «хто ти?», 403 — «тобі можна?». 401 — сервер не знає, хто ти: токен відсутній, прострочений або підроблений; це проблема автентифікації (authentication), і реакція клієнта — залогінитися чи оновити токен. 403 — сервер тебе впізнав, але цьому користувачеві сюди не можна: звичайний юзер лізе в адмінку; це проблема авторизації (authorization), і повторний логін нічого не змінить. За специфікацією (RFC 9110) відповідь 401 мусить містити заголовок WWW-Authenticate, хоча на практиці цю вимогу часто порушують. Для AQA різниця не педантизм: у тесті ролей, де залогінений юзер перевіряє недоступність адмін-ендпоінта, правильна відмова — 403, і асерт на 401 тут бреше. А 401 замість 403 (чи навпаки) на реальному ендпоінті — це вже знахідка, яку тест на статус і має зловити.

Автотест несподівано отримав 404. Які версії треба перевірити перед тим, як писати баг?

404 означає, що ресурсу за цією адресою немає, але це маскує кілька різних причин. Або даних справді немає (ніколи не було чи видалено), або URL зібрано неправильно — одрук у слагу, неправильний ID, не те середовище, — або фікстура не створила потрібний запис перед тестом. Тому перше питання при несподіваному 404 — «а той запис чи маршрут узагалі існує в цьому середовищі?». Перевіряється це просто: повторити запит вручну з явним ID і подивитися, що реально підставилось у URL тесту. Часто виявляється, що баг у тесті чи в підготовці даних, а не в продукті.

Чому в тесті треба перевіряти числовий код, а не текст «OK» чи «Not Found»?

Машина орієнтується на число, а текстова фраза (reason phrase) призначена для людини. Фраза може відрізнятися між серверами, а в HTTP/2 і HTTP/3 її в протоколі немає взагалі — передається лише код. Тобто асерт на текст ламається від зміни сервера чи версії протоколу, хоча поведінка API не змінилась. Тому в тесті правильно перевіряти response.status() === 200, а не текстовий рядок статусу.

Чим відрізняються 301 і 302, і навіщо придумали 307 і 308?

301 Moved Permanently — ресурс переїхав назавжди, клієнти й пошуковики можуть закешувати новий шлях; 302 Found — переїзд тимчасовий, канонічною лишається стара адреса. Історична пастка обох: браузери на практиці перетворювали POST на GET при перенаправленні й губили тіло запиту, і RFC 9110 прямо визнає, що клієнт може так робити «з історичних причин». Саме тому зʼявилися явні коди без двозначності: 307 Temporary Redirect і 308 Permanent Redirect зберігають і метод, і тіло (308 додано пізніше окремим RFC 7538 як «постійний брат» 307). Просте правило: треба перенаправити POST/PUT/DELETE без втрати тіла — це 307/308, а не 301/302. Побіжно існує ще 303 See Other, який навпаки навмисно змушує клієнта зробити GET — наприклад, після обробки форми.

На старому URL налаштований редірект, але тест бачить 200. Чому, і як перевірити сам факт редіректу?

Браузери й більшість HTTP-клієнтів за замовчуванням автоматично йдуть за перенаправленнями (follow redirects), тому в коді видно вже фінальний 200, навіть якщо між ним був 301 — помітний виняток curl, який без прапорця -L за редіректом не піде. Це зручно для звичайних тестів, але ховає сам редірект. Щоб перевірити його явно (наприклад, http→https чи старий URL→новий), автопрямування треба вимкнути й асертити проміжний код разом із заголовком Location: у Playwright APIRequestContext це maxRedirects: 0, після чого expect(res.status()).toBe(301) і перевірка res.headers()['location']. Окремий практичний нюанс: у UI-тестах ланцюжок редіректів — часте джерело флаку, бо очікування чекає на URL, який зʼявляється лише на мить; надійніше чекати на фінальний стан сторінки, а не на проміжний URL.

Що означає 409 Conflict і про що він сигналить, якщо зʼявляється при повторних запусках тестів?

409 — запит валідний, але конфліктує з поточним станом ресурсу: реєстрація на вже зайнятий email, дублікат унікального запису, конфлікт одночасного редагування. У контексті автотестів це прямий сигнал про проблему ізоляції стану: якщо тест створює юзера з фіксованим email і на повторному прогоні отримує 409, значить, попередній прогін не прибрав за собою. Лікування стандартне — унікальні дані на кожен прогін (email з таймстемпом чи UUID) плюс надійне прибирання (teardown/cleanup). Тобто 409 у CI частіше вказує на дизайн тестових даних, ніж на баг продукту — але на реальному флоу реєстрації це якраз очікувана й правильна відповідь, яку варто покрити окремим негативним тестом.

У чому різниця між 400 Bad Request і 422 Unprocessable Content?

400 — запит зламаний на рівні синтаксису чи форми: невалідний JSON, некоректний формат — сервер не може його навіть розібрати. 422 — запит синтаксично коректний, сервер його розібрав, але вміст не проходить бізнес-валідацію: вік відʼємний, дата в минулому там, де має бути майбутнє. Простими словами: 400 — «я не зрозумів, що ти написав», 422 — «я зрозумів, але так не можна». Історична деталь: 422 прийшов зі світу WebDAV (RFC 4918), тепер внесений до RFC 9110 і перейменований з Unprocessable Entity на Unprocessable Content — обидві назви ще трапляються в документації. Практичний наслідок для тестів: фреймворки поводяться по-різному, одні на помилку валідації віддають 422, інші 400, тому в негативному сценарії не варто наосліп асертити 400 — треба звірятися з контрактом конкретного API. І навпаки: якщо API документує 422, а повертає 400 чи взагалі 500 — це знахідка.

Що таке 429 Too Many Requests і чому тести з ним падають лише в CI?

429 — обмеження частоти запитів (rate limiting): клієнт зробив забагато звернень за проміжок часу; код визначено в RFC 6585. Відповідь може містити заголовок Retry-After — скільки чекати перед наступною спробою (число секунд або конкретна HTTP-дата). Для AQA це одне з найпідступніших джерел флаку: кілька паралельних воркерів у CI одночасно гатять в один ендпоінт, спрацьовує ліміт — і частина тестів червоніє «випадково». Симптом упізнаваний: локально все зелене, а в пайплайні з паралелізмом — плавучі падіння. Рецепти: поважати Retry-After у ретраях, зменшити паралелізм на «гарячих» ендпоінтах, а в чистих UI-тестах — перехоплювати мережу й мокати ліміт, якщо мета тесту не в самому rate-limiting.

Як працює 304 Not Modified і механізм умовних запитів?

304 формально належить до 3xx, але за суттю це не «піди в інше місце», а «нічого не змінилося, бери своє з кешу» — серце умовних запитів (conditional requests), які економлять трафік. Механізм: віддаючи ресурс, сервер додає валідатор — ETag (унікальний відбиток вмісту) або Last-Modified (дату останньої зміни). Наступного разу клієнт питає умовно: If-None-Match з ETag-ом або If-Modified-Since з датою — «віддай, тільки якщо змінилося». Якщо не змінилося, сервер відповідає 304 без тіла — воно й не потрібне, бо актуальна копія вже є у клієнта. Пари жорсткі: If-None-Match працює з ETag, If-Modified-Since — з Last-Modified. У тестах про це варто памʼятати, коли асертиш тіло відповіді: після 304 тіла немає, дані беруться з кешу клієнта.

Тест зелений поодинці, але червоний у повному наборі. До чого тут 304 і кеш?

Кешування — прихована причина «стану, що протікає» між тестами. Сценарій: тест A завантажив сторінку й наповнив кеш; тест B робить той самий запит, отримує 304 і старі дані, хоча очікує свіжі після своїх змін. Особливо підступно це в API-тестах, де один клієнтський контекст переживає кілька кейсів. Симптом класичний: результат залежить від порядку запуску тестів — тоді 304 і кеш перший підозрюваний. Лікування — примусова ізоляція стану: чистий контекст на кожен тест, заголовок Cache-Control: no-cache у запитах або відключення кешу браузера.

Чим відрізняються 500, 502, 503 і 504?

Усі чотири — серверні помилки, але вказують на різні місця поломки в топології «браузер → проксі/балансувальник → застосунок → база». 500 Internal Server Error — застосунок дійшов до запиту й впав з необробленим винятком: найзагальніший код, «щось пішло не так усередині». 502 Bad Gateway — проксі звернувся до свого апстріму (upstream), а той віддав щось нечитабельне або взагалі не піднявся: проксі стоїть, апстрім — ні. 503 Service Unavailable — сервіс свідомо каже «зараз не можу»: перевантаження, деплой, обслуговування; часто з Retry-After, і це радше «зайди пізніше», ніж «я зламався». 504 Gateway Timeout — проксі не дочекався відповіді апстріму у відведений час: апстрім, імовірно, живий, але надто повільний (важкий запит до БД, завислий зовнішній виклик). Практичний висновок для прогонів: масові 502/503/504 одразу після релізу — частіше стан середовища (деплой у процесі, стейдж прогрівається), ніж баг продукту; спершу переконайся, що середовище взагалі піднялося, а вже потім заводь дефект.

API повертає 404 замість 403 на ресурс, до якого немає прав. Це баг?

Не обовʼязково — частина реальних API робить це навмисно, щоб не розкривати сам факт існування закритого ресурсу: для стороннього приватний ресурс виглядає як неіснуючий. Тобто формально «неправильний» код може бути свідомим рішенням контракту з міркувань безпеки. Наслідок для тестування: перед написанням асерту на код відмови треба звірятися з контрактом конкретного API, а не з «як має бути за підручником». Якщо контракт документує 404 на чужі ресурси — тест асертить 404; якщо контракт каже 403, а приходить 404 — це вже привід для розмови з командою. Сильна відповідь тут показує, що кандидат розрізняє «відхилення від специфікації» і «відхилення від контракту продукту».

Тест шле завідомо невалідний JSON, а сервер відповідає 500. Це очікувана поведінка?

Ні — це вже щонайменше «півбага» бекенда. Добре спроєктований сервер на будь-який кривий ввід має відповісти 400 чи 422, тобто свідомою помилкою клієнта, а не падати з необробленим винятком. 500 на сміттєвому вводі означає пропущену валідацію: якийсь шар коду спробував опрацювати те, що мав відхилити на вході. При цьому фіксувати варто обидві складові: тригер прийшов від клієнта чи тесту (кривий ввід), але реакція сервера — окремий дефект бекенда. Саме тому негативні тести з невалідними даними цінні: вони перевіряють не тільки повідомлення про помилку, а й те, що сервер відмовляє контрольовано, кодом 4xx, а не падає.

Автотест отримав 500. Як зрозуміти, чий це баг — фронта, бекенда чи самого тесту?

Базовий принцип: 5xx завжди повертає сервер, і це майже завжди вказує щонайменше на одну проблему на бекенді, але тригер міг прийти з будь-якої ланки, тому діагностика йде по кроках. Крок 1 — подивитися на сам запит: URL, метод, заголовки (особливо Authorization і Content-Type), тіло; якщо запит криво зібраний, імовірний тригер на боці фронтенду або тесту, але бекенд усе одно мав відповісти 4xx. Крок 2 — відтворити вручну той самий запит через curl чи Postman: відтворюється валідним запитом — кандидат на баг бекенда; не відтворюється, а тест падає — підозра зміщується на тест (не підставилась змінна, протух токен, крива фікстура, не те середовище). Крок 3 — логи сервера: 500 майже завжди лишає стектрейс, який прямо показує, де впало, — це і є доказ замість «здається». Крок 4 — відділити середовище від продукту: чи це справді 500, а не масові 502/503/504 через деплой чи навантаження; окремий патерн — 500 лише в CI під паралелізмом, а поодинці зелено, тоді розкопуй ізоляцію стану, гонки чи rate limit. Головна дисципліна: не заявляти причину без перевірки — «схоже на баг бекенда, стектрейс указує на конкретний контролер» коштує рівно стільки, скільки під ним доказів.

Три кейси, у яких статус-код — головний інструмент діагностики: перевірка самого факту редіректу з вимкненим автопрямуванням, тест ролей на 401 vs 403 із пасткою контракту 201/204, і покроковий тріаж «отримав 500 — чий це баг». Скрізь — що дивитися і чому.

Кейс 1. Перевіряєш редірект, а не фінальний 200

Задача — переконатися, що старий шлях назавжди переїхав на новий (http→https, /old→/new). Пастка в тому, що більшість клієнтів за замовчуванням самі йдуть за перенаправленням (follow redirects), тож у коді ти бачиш уже фінальний 200 — і проміжний 301 тест просто не помічає. Виняток — curl, який без -L за редіректом не піде:

curl -i https://app.example.com/old-path

HTTP/1.1 301 Moved Permanently
Location: https://app.example.com/new-path
Content-Length: 0

Щоб асертити сам редірект в автотесті, автопрямування треба вимкнути — тоді видно проміжний код і Location:

import { test, expect, request } from '@playwright/test';

test('старий шлях віддає постійний редірект на новий', async ({ playwright }) => {
  const api = await request.newContext({ baseURL: 'https://app.example.com' });

  const res = await api.get('/old-path', { maxRedirects: 0 });

  expect(res.status()).toBe(301);
  expect(res.headers()['location']).toBe('https://app.example.com/new-path');
});

Що дивитися і чому:

• maxRedirects: 0 — без нього тесту нема. З автопрямуванням res.status() буде 200 кінцевої сторінки, і асерт на 301 неможливий у принципі. Вимкнув прямування — отримав саме проміжну відповідь.
• 301 vs 302 — це контракт, не косметика. 301 каже клієнтам і пошуковикам «кешуйте новий шлях назавжди». Якщо чекаєш 301, а прилетів 302 (тимчасовий), — це легітимна претензія до контракту: тимчасовий редірект не дозволяє закешувати переїзд.
• Заголовок location читай у нижньому регістрі. У Playwright res.headers() віддає імена заголовків уже нормалізованими в lower-case, тож headers()['Location'] поверне undefined.
• Для POST/PUT/DELETE дивись на 307/308. Якщо редіректиться запит із тілом, а сервер віддає 301/302, браузер історично може підмінити метод на GET і згубити тіло. Зберігають метод і тіло тільки 307/308.

У UI-тесті надійніше не чекати на проміжний URL редіректу (він зʼявляється лише на мить — часте джерело флаку), а асертити фінальний стан сторінки.

Кейс 2. Тест ролей: 401 vs 403 і контракт 201/204

Класичний негативний сценарій: звичайний користувач не має лізти в адмін-ендпоінт. Інтуїція підказує асертити 401 — і це помилка. Юзер якраз автентифікований (токен валідний), тож правильна відмова — 403, а не 401.

import { test, expect, request } from '@playwright/test';

test('звичайний юзер не створює адмінів (403, не 401)', async ({ playwright }) => {
  const api = await request.newContext({ baseURL: 'https://api.example.com' });

  // логін звичайним юзером — токен валідний
  const login = await api.post('/api/login', {
    data: { email: 'user@example.com', password: 'secret' },
  });
  const { token } = await login.json();

  const res = await api.post('/api/admins', {
    headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
    data: { email: 'new-admin@example.com' },
  });

  // 401 тут — БРЕХНЯ: юзер автентифікований, йому просто не можна
  expect(res.status()).toBe(403);
});

Що дивитися і чому:

• 401 = «хто ти?», 403 = «тобі можна?». 401 — не автентифікований (немає/протух/невалідний токен), лікується логіном. 403 — автентифікований, але роль без прав; повторний логін не допоможе. Асертиш 401 там, де сервер відповідає 403, — тест зелений з неправильної причини або червоний на коректній поведінці.
• 401↔403 на реальному ендпоінті — це знахідка. Якщо продукт віддає 401 замість 403 (чи навпаки), тест на статус саме це й має зловити — це баг контролю доступу, а не причепка.
• Звіряйся з контрактом: буває 404 замість 403. Частина API навмисно ховає закриті ресурси під 404, щоб не розкривати сам факт їхнього існування. Тому асерт пиши під задокументовану поведінку конкретного API, а не «за інтуїцією».

Дзеркальна пастка — на позитивному боці. Ендпоінт створення після рефакторингу чесно віддає 201 Created замість 200, або DELETE віддає 204 No Content — і тест падає на рівному місці:

// створення повертає 201 + Location, а не 200
const created = await api.post('/api/users', {
  headers: { 'Content-Type': 'application/json' },
  data: { name: 'Grace', email: 'grace@example.com' },
});
expect(created.status()).toBe(201);
expect(created.headers()['location']).toBeTruthy();

// видалення повертає 204 БЕЗ тіла — .json() тут впаде
const removed = await api.delete('/api/users/43');
expect(removed.status()).toBe(204);
// await removed.json(); // ← помилка парсингу: тіла немає й не мало бути

201 замість 200 на створенні — часто легітимна вимога контракту (201 ще й несе Location з адресою нового ресурсу). А await res.json() після 204 дає помилку парсингу порожнього тіла: тест «червоний», хоча функціонал справний — просто тіла там і не буває.

Кейс 3. «Отримав 500 — це баг фронта, бекенда чи тесту?»

Це питання ставлять на кожній співбесіді. Плутанина в тому, що 5xx завжди повертає сервер, але спричинити його може будь-яка ланка. Порядок дій — від запиту до логів, без «здається».

Крок 1. Подивись на сам запит. URL, метод, Authorization, Content-Type, тіло. Якщо запит криво зібраний (немає обовʼязкового поля, зламаний JSON) — імовірний тригер на боці клієнта чи тесту. Але зафіксуй і бекенд-складову: на кривий ввід добре спроєктований сервер мусить відповісти 400/422, а не падати з 500. Неопрацьований 500 на смітті — це вже щонайменше півбага бекенда (пропущена валідація).

Крок 2. Відтвори вручну. Повтори точно той самий запит поза тестом:

curl -i -X POST https://staging.example.com/api/users \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <token>' \
  -d '{"name":"Grace","email":"grace@example.com"}'

• Відтворюється валідним запитом → проблема стабільна, на боці сервера. Кандидат на баг бекенда.
• Не відтворюється, а тест усе одно падає → підозра зміщується на тест: не підставилась змінна, протух токен, крива фікстура, не те середовище.

Крок 3. Прочитай логи. 500 майже завжди лишає стектрейс (stack trace) у логах застосунку — він прямо показує рядок коду і причину падіння. Без вимірюваного доказу не заявляй root cause: стектрейс і є той доказ. Формулювання «схоже на баг бекенда, стектрейс указує на UsersController#create» коштує рівно стільки, скільки під ним доказів.

Крок 4. Відділи середовище від продукту. Це справді 500 чи насправді 502/503/504? Масові однотипні 5xx одразу після релізу — частіше про інфраструктуру (деплой у процесі, стейдж прогрівається, база під навантаженням), ніж про логіку продукту.

Швидкий висновок за симптомом:

Останній рядок — про підступний флак: паралельні воркери (workers) або незачищені дані дають 409 Conflict (email уже зайнятий) чи 429 Too Many Requests (спрацював rate limit). Симптом упізнаваний — локально зелено, у пайплайні плавучі падіння. Лікування: унікальні дані на прогін (email з таймстемпом/UUID), надійний teardown, повага до Retry-After у ретраях.

Анатомія та класи

• Знаю, що статус-код — трицифрове число у стартовому рядку відповіді, і що машина орієнтується на код, а не на текстову фразу (reason phrase), якої в HTTP/2 і HTTP/3 узагалі немає.
• Розумію, чому в тесті треба асертити response.status() === 200, а не текстовий рядок.
• Можу пояснити пʼять класів за першою цифрою (1xx, 2xx, 3xx, 4xx, 5xx) і що ключова лінія розлому — між 4xx («винен клієнт, виправляй запит») і 5xx («винен сервер»).

2xx — успіх

• Знаю різницю між 200 OK, 201 Created (новий ресурс + заголовок Location) і 204 No Content (успіх без тіла).
• Розумію, чому спроба зробити res.json() після 204 падає з помилкою парсингу, хоча функціонал працює.
• Можу пояснити, чому асерт toBe(200) червоніє, коли ендпоінт створення чесно перейшов на 201, і чому 200 замість 201 — це претензія до контракту.

3xx — перенаправлення і кеш

• Знаю різницю 301 (постійно) vs 302 (тимчасово) і чому 307/308 зберігають метод і тіло, а 301/302 історично могли перетворити POST на GET.
• Розумію правило: щоб перенаправити POST/PUT/DELETE без втрати тіла — це 307/308, а не 301/302.
• Можу пояснити, чому клієнти автоматично йдуть за редіректами (крім curl без -L) і як явно перевірити редірект через maxRedirects: 0 + асерт Location.
• Розумію, чому ланцюжок редіректів — часте джерело флаку в UI-тестах, і що чекати треба фінальний стан, а не проміжний URL.
• Можу пояснити 304 Not Modified як серце умовних запитів: If-None-Match працює з ETag, If-Modified-Since — з Last-Modified, тіла немає.
• Розумію, чому кеш і 304 — перший підозрюваний, коли тест то зелений, то червоний залежно від порядку запуску.

4xx — помилка клієнта

• Знаю різницю 401 («хто ти?», не автентифікований, має бути WWW-Authenticate) vs 403 («тобі можна?», автентифікований, але без прав) і чому повторний логін при 403 не поможе.
• Можу пояснити, чому в тесті ролей на закритий ендпоінт правильна відмова — 403, а асерт 401 бреше.
• Розумію, чому деякі API навмисно віддають 404 замість 403, щоб не розкривати існування ресурсу.
• Знаю, що 404 маскує кілька причин (одрук у слагу, неправильний ID, фікстура не створила запис), тому перше питання — «а запис/маршрут узагалі є в цьому середовищі?».
• Можу пояснити 409 Conflict (зайнятий email, дублікат, конкурентне редагування) як прямий сигнал проблеми ізоляції стану — лікування унікальними даними й teardown.
• Знаю різницю 400 («не зрозумів синтаксис») vs 422 («зрозумів, але вміст не проходить бізнес-валідацію») і що різні фреймворки віддають то одне, то інше — треба звірятися з контрактом.
• Можу пояснити 429 Too Many Requests (rate limiting, заголовок Retry-After) як підступне джерело флаку під паралелізмом у CI.

5xx і діагностика

• Знаю різницю 500 (виняток у застосунку), 502 (апстрім віддав некоректну відповідь), 503 (сервіс свідомо «зараз не можу») і 504 (шлюз не дочекався апстріму).
• Розумію, чому масові 502/503/504 після релізу — частіше про середовище, ніж про баг у продукті.
• Можу пояснити діагностику 500 по кроках: подивись запит → відтвори вручну (curl/Postman) → прочитай логи (стектрейс) → відділи середовище від продукту.
• Розумію принцип, що навіть на криве сміття добрий бекенд має відповісти 4xx, а не впасти з 500, і що причину не заявляють без вимірюваного доказу (стектрейс).