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

Що таке HTTP статус-код і що каже його перша цифра?

Це тризначне число на початку відповіді, яким сервер підсумовує долю запиту: опрацьовано чи ні і що покладено у відповідь. Валідні значення вкладаються в проміжок від 100 до 599, а перша цифра ділить їх на пʼять класів і задає клієнтові стратегію реакції. 1xx — відповідь проміжна, остаточна прийде слідом; 2xx — запит виконано, читай тіло й заголовки; 3xx — із запитом усе гаразд, але потрібен ще один крок; 4xx — проблема в самому запиті; 5xx — запит виглядав валідним, а спіткнувся сервер. Для тестувальника це найдешевша діагностика: число вже показує, на чиєму боці шукати винного, ще до логів і коду. Конкретний код (401 це чи 403, 502 чи 503) уточнює картину, але напрямок пошуку задає клас.

Чому в автотестах асертять число коду, а не текст поруч із ним?

Бо пояснювальна фраза (reason phrase) — ненадійний канал. RFC 9110 вважає її необовʼязковою, RFC 9112 вимагає, щоб клієнт на неї не спирався, у HTTP/2 статус приїжджає єдиним псевдозаголовком :status, а HTTP/3 місця під таку фразу не має взагалі. Тобто сервер, посередник чи зміна версії протоколу можуть переписати OK на будь-що, і жодна специфікація цього не порушить. Асерт «текст відповіді дорівнює Not Found» ламається на рівному місці, асерт на 404 — ні. Це той рідкісний випадок, коли правильна практика випливає прямо з букви специфікації, а не з досвіду.

Де проходить головна межа: 4xx проти 5xx?

Там, де змінюється адресат претензії. 4xx означає, що з запитом щось не так — синтаксис, дані, права, метод, формат; виправляти треба на боці клієнта. 5xx означає, що запит виглядав нормальним, а зламався сам сервер. Практичний наслідок для баг-репорта: 4xx веде до самого запиту — тесту, фікстур, контракту, — а 5xx до бекенду й інфраструктури. Є одне важливе перехрестя: на відверто кривий ввід сервер має відповісти кодом класу 4xx, і якщо він натомість падає з 500, це самостійна знахідка, навіть коли ввід справді сміттєвий. Тобто 500 на негативному тесті — не «очікувано, бо дані погані», а баг.

Чим 201 Created відрізняється від 200 OK і навіщо це знати тестувальнику?

200 — універсальний успіх, зміст якого залежить від методу; 201 повідомляє більше: у результаті запиту зʼявився новий ресурс. Типове місце — POST і частина PUT, а адресу новоствореного ресурсу за домовленістю кладуть у заголовок Location. Для QA тут дві сторони однієї монети. З одного боку, 200 на створення — легітимна претензія до API: код недоговорює, клієнту нема звідки взяти адресу створеного обʼєкта. З іншого — жорсткий expect(200) у твоєму тесті зламається того дня, коли бекенд почне чесно віддавати 201, і це буде падіння тесту, а не регресія продукту. Тому асерт на статус варто читати як перевірку контракту, а не як «щось повернулося».

Тест успішно виконав запит, але падає на розборі JSON. Що могло статися?

Найпоширеніший сценарій — 204 No Content: запит опрацьовано, але тіла у відповіді немає й не мало бути. Парсер отримує порожній рядок, кидає помилку, і в звіті це виглядає як зламаний ендпоінт, хоча насправді все відпрацювало штатно. Значуща інформація в такій відповіді лежить у заголовках, і саме їх треба перевіряти. Той самий симптом дає 304 Not Modified і будь-яка відповідь на HEAD. Правильна реакція — не «сервер повернув порожнечу», а перевірка коду перед парсингом: спершу статус, потім тіло, і лише якщо воно за контрактом має бути.

У яких випадках тіла у відповіді немає за правилами, а не через баг?

Таких упізнаваних випадків три: відповідь на HEAD, 204 No Content і 304 Not Modified. Для HEAD це навіть не домовленість, а заборона: надсилати вміст серверу не дозволено, бо метод існує заради самих метаданих. 204 каже «успіх, показувати нема чого», 304 — «бери свою збережену копію». Порожнеча тут не збій: усе потрібне лежить у заголовках, і саме їх треба читати замість тіла. У запитах картина дзеркальна: тіло зазвичай везуть POST, PUT і PATCH, тоді як тіло в GET синтаксис пропускає, але загальновизначеного змісту воно не має і ціль запиту не змінює — тому громіздкі критерії пошуку відправляють окремим POST, а не пхають у GET.

Коли сервер має відповісти 405, а коли 415?

Ці коди відповідають на різні питання, хоч обидва звучать як «мені це не підходить». 405 Method Not Allowed — про дієслово: серверу метод знайомий, просто конкретний ресурс із ним не працює. Класична ситуація — DELETE на колекцію, яка вміє тільки GET і POST: адреса правильна, дія — ні. 415 Unsupported Media Type — про формат вмісту, тобто про Content-Type чи Content-Encoding: сервер відмовляється розбирати те, що ти прислав. Це важлива деталь для негативних тестів: канонічна відповідь на кривий або непідтримуваний Content-Type — саме 415, а не загальний 400.

Де межа між 400 і 422?

400 Bad Request виставляють, коли сервер відмовляється братися за запит через помилку на боці клієнта — типово через побитий синтаксис. 422 Unprocessable Content означає, що запит зібраний коректно, але виконати його не вийде через семантику. Найкоротша формула, яка добре заходить на співбесіді: 400 — «я не розібрав, що ти написав», 422 — «я все розібрав, але так не буває». Приклад різниці: обірваний JSON — це 400, а синтаксично бездоганний JSON з віком -5 або датою виїзду раніше за дату заїзду — це 422. Обидва коди сидять у класі 4xx, тобто в обох випадках правити треба запит; різниця в тому, що саме правити — форму чи зміст.

Що означає 409 Conflict і чим він відрізняється від 400 та 422?

409 — це конфлікт запиту з поточним станом ресурсу: email уже зайнятий, запис із таким ключем існує, документ хтось редагує паралельно. У продуктовому сенсі це нормальна ділова відповідь, а не поломка: запит і зібраний коректно, і зрозумілий, просто виконати його заважає те, що вже лежить на сервері. Звідси й межа із сусідами по класу: 400 і 422 кажуть правити сам запит — форму або зміст, — а 409 каже, що із запитом усе гаразд і справа в тому, що вже лежить на сервері. Для тесту з цього випливає конкретна річ: сценарій створення з фіксованою поштою на другому прогоні законно отримає 409, бо ця пошта вже зайнята першим, — і правити тут треба тестові дані, а не продукт.

Що таке 429 і чому він робить пайплайн нестабільним?

429 Too Many Requests означає, що клієнт перевищив дозволену частоту звернень; відповідь може нести заголовок Retry-After, у якому вказано, скільки чекати, — невідʼємне число секунд або HTTP-дата. Симптом у CI дуже впізнаваний: локально все зелене, а в пайплайні тести плавають без жодної логіки. Причина зазвичай механічна — паралельні воркери одночасно гатять в той самий ендпоінт, ліміт спрацьовує, і частина запитів отримує відмову замість даних. Лікується це не збільшенням таймаутів, а трьома речами: ретраї мають читати Retry-After, паралелізм на найгарячіших ендпоінтах варто зрізати, а мережу — замокати там, де сам ліміт перевіряти не треба. Окремо варто памʼятати: якщо ти тестуєш саме rate limiting, 429 — очікуваний результат, і глушити його не можна.

Чим 401 відрізняється від 403?

401 Unauthorized відповідає на питання «хто ти?», 403 Forbidden — на питання «тобі можна?». За каноном 401 означає брак валідних облікових даних, і така відповідь мусить нести заголовок WWW-Authenticate — на практиці цю вимогу порушують регулярно. 403 означає, що сервер запит зрозумів і виконувати його відмовляється; повторний вхід тут нічого не змінить, бо стадія автентифікації вже пройдена. Плутанину підживлюють самі назви: 401 називається «Unauthorized», хоча йдеться про автентифікацію. Розвести поняття допомагає глосарій ISTQB: автентифікація — це процедура встановлення особи, авторизація — наданий дозвіл. І окремий нюанс, за який дають бали: якщо облікові дані валідні, але їх повноважень бракує, коректна відповідь — 403, і браузер, на відміну від 401, нової спроби входу вже не запропонує.

Прийшов 403. Чи можна з цього зробити висновок, що бракує ролі?

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

Що таке 407 і чим він відрізняється від 401?

407 Proxy Authentication Required — це той самий сюжет про «назвися», але вимагає автентифікації не цільовий сервер, а проксі між тобою і ним. Пара заголовків тут своя: Proxy-Authenticate у відповіді й Proxy-Authorization у наступному запиті. Для QA це насамперед підказка при дебагу корпоративного оточення: якщо запити зі стенда всередині мережі отримують 407, справа не в застосунку і не в токені користувача, а в тому, що трафік іде крізь проксі, який хоче свої облікові дані. Плутати 407 з 401 — типова помилка: перший заводить у дебрі коду автентифікації застосунку, хоча правильне місце пошуку — мережева конфігурація.

У чому різниця між 301, 302, 307 і 308?

Усередині класу 3xx працюють дві незалежні осі, і плутають їх саме тому, що намагаються запамʼятати чотири коди списком. Перша вісь — постійність: 301 і 308 кажуть, що адреса змінилася назавжди і стару використовувати більше не варто, 302 і 307 — що переїзд тимчасовий. Друга вісь — доля методу й тіла: 307 і 308 переносять їх у наступний запит без змін, а 301 і 302 дозволяють клієнту підмінити метод на GET, і тіло при цьому губиться. Історія тут така: специфікація зміни методу не передбачала, але реальні клієнти її робили — тож 307 і 308 додали, щоб зафіксувати сувору поведінку явно. Дві деталі для сильної відповіді: нормативно RFC 9110 забороняє підміняти метод тільки в описі 307, а незмінність тіла документує MDN; і хоча 308 колись жив окремим документом, з 2022 року його визначає той самий RFC 9110.

Сервер відповів 301 на POST. Що станеться з методом і тілом?

Метод може перетворитися на GET, а тіло — просто зникнути, і формально це не баг клієнта: коди 301 і 302 таку підміну допускають. Виглядає це в тестах дуже неприємно: запит нібито пройшов, фінальна відповідь 200, але дані на сервер не доїхали, бо друга частина ланцюга була вже іншим запитом без тіла. Якщо потрібно, щоб POST лишився POST, правильні коди — 307 (тимчасово) і 308 (постійно). Додаткова складність у тому, що браузери й більшість HTTP-клієнтів ідуть за редиректом (redirect) автоматично, тож у коді видно лише фінальний результат; помітний виняток — curl, який без прапорця -L за редиректом не піде. Саме тому редирект варто перевіряти явно: вимкнути автопрямування, заасертити проміжний код і заодно заголовок Location.

Навіщо існує 303 See Other, якщо є 302?

303 — єдиний із родини, який змінює метод на GET навмисно, а не «дозволяє клієнту». Класичне застосування — після обробки форми: сервер приймає POST, виконує дію і відправляє браузер забрати результат окремим GET. Тіло вихідного запиту при цьому не переноситься, і це закладена поведінка, а не втрата. Різниця з 302 тонка, але саме її люблять питати: 302 описує тимчасовий переїзд і мовчазно допускає підміну методу, а 303 цю підміну робить частиною свого змісту. Поруч у класі живуть ще два коди, які не є редиректом у звичному сенсі: 300 Multiple Choices пропонує вибрати варіант вручну, а 304 Not Modified відправляє клієнта до його ж локальної копії.

Що означає 304, хто його ініціює і чи застаріла копія в кеші?

Ініціює його клієнт: коли віддати збережену відповідь напряму вже не можна, кеш іде на сервер із умовним запитом (conditional request) і додає валідатор — збережений ETag їде в заголовку If-None-Match, а дата з Last-Modified — в If-Modified-Since. Сервер порівнює валідатор і, якщо ресурс не змінився, відповідає 304 без тіла: збережену копію можна оновити метаданими й використати повторно, трафік на тіло не витрачається. Тепер тонкість, на якій ловлять: копія в цей момент не застаріла, а валідна — RFC виходить із того, що клієнт уже має придатне подання ресурсу, і сервер лише каже скористатися ним так, ніби це тіло відповіді 200. Формулювання «сервер підтвердив, що стара копія ще годиться» — побутове й нешкідливе, а от «копія була протухла» суперечить специфікації. Для тестів 304 у мережевій панелі — ознака робочої ревалідації, а не помилки.

Чому 404 в API — неоднозначний код?

Тому що під ним ховаються щонайменше три різні історії. Перша — маршруту не існує взагалі: друкарська помилка у слазі, звернення до старої версії API, не той префікс. Друга — маршрут є, а обʼєкта немає: запис видалили, фікстура не створилася, тест дивиться не в те середовище. Третя — заборона, яку сервер навмисно замаскував, щоб не розкривати існування ресурсу. Корінь неоднозначності термінологічний: ресурс — поняття концептуальне, це відображення на певний набір сутностей, а не сама сутність, зафіксована в моменті, тоді як ендпоінт — просто адреса, за якою до нього стукають. Є й четверте, суто технічне джерело: регістр байдужий схемі й хосту, але не шляху й рядку запиту, тож /api/Users/42 і /api/users/42 це різні адреси. Тому рефлекс при 404 — не заводити баг, а поставити три питання: чи взагалі є такий маршрут, чи лежить потрібний запис саме в цьому середовищі і чи не маскує код відмову.

Прийшов 502. Де шукати причину і чим від нього відрізняється 503?

502 Bad Gateway за означенням віддає не застосунок, а вузол, що працює як шлюз (gateway) чи проксі й отримав від внутрішнього сервера відповідь, яку не зміг визнати валідною; 504 Gateway Timeout — той самий вузол у тій самій ролі, тільки відповіді він не дочекався. Обидва означають «зламалася ланка за посередником», і застосунок про такий запит міг узагалі не дізнатися — тому шукати причину в його коді марно, дивитися треба на балансувальник, шлюз і те, що за ними. 503 Service Unavailable до цієї родини не належить, хоч його туди регулярно записують: він каже, що сам сервіс тимчасово не здатен обробити запит — перевантаження або планові роботи. 500 Internal Server Error лишається загальною відмовкою: сервер не знає, що робити, і доречнішого коду в класі 5xx не має. Практичне продовження відповіді: масові однотипні 502 чи 504 одразу після релізу частіше означають, що середовище ще не піднялося, ніж що в продукті зʼявився баг, — спершу перевіряють стенд, і лише потім заводять тікет.

Чому в OAuth-флоу 401 не завжди означає «протухла сесія»?

Бо в делегованому доступі 401 — це штатний сигнал у нормальному житті токена: access-токен короткоживучий, і відповідь 401 каже клієнту оновити його через refresh і повторити запит. Тобто одиничний 401 у логах такого флоу — не інцидент, а частина протоколу. Друга типова причина «раптового 401» ще підступніша: заголовок Authorization знімається на крос-оріджин редиректі, тож клієнт токен слав, а до цільового сервера він не доїхав. Поруч живуть ще два готові негативні тести з тієї ж області: код авторизації одноразовий і короткоживучий, тож повторний обмін того самого коду має провалитися; а при невідповідному redirect_uri сервер має сказати про це власникові ресурсу й нікого на непідтверджену адресу не відправляти — тому очікувати там 3xx неправильно. І термінологічна межа, яку люблять питати поруч: OAuth 2.0 — про авторизацію, а автентифікацію дає надбудова над ним, OpenID Connect, на яку технічно спирається звичний «вхід через Google».

Три кейси, у яких статус-код вирішує, куди піде наступна година: триаж червоної сюїти за кодами замість читання логів наосліп, асерт контракту створення й редиректу в Playwright і негативний тест прав, який не ламається від того, що сервер приховав ресурс. Скрізь — що дивитися і чому саме так.

Кейс 1. Ранкова сюїта червона: триаж за кодом

Класична картина понеділка: 40 упалих тестів, у кожному «request failed». Перш ніж відкривати логи застосунку, варто витягнути зі звіту самі коди — вони вже сортують проблему за адресатом. Перша цифра каже, на чиєму боці шукати, конкретний код підказує перше місце.

Далі — два вузли, у яких найчастіше плутають адресата.

• Однотипні 502/503/504 на всій сюїті одразу після релізу — спершу стан середовища, а не баг продукту. Застосунок цих кодів міг не віддавати взагалі: 502 і 504 приходять від шлюзу, який не дочекався або не зрозумів внутрішній сервер. Заводити тікет на продукт, поки стенд не піднявся, — гарантований спосіб витратити день на чужу проблему.
• 500 не «пробачають» через поганий ввід. Якщо негативний тест шле сміття і отримує 500, це окрема знахідка: коректною відповіддю тут був би 400 чи 422. Тест при цьому може бути формально зеленим, якщо в асерті стоїть «код не з класу 2xx» — і саме так реальні дефекти проїжджають повз.
• 429 виглядає як флак, але має адресу. Симптом дуже характерний: на локальній машині все стабільно, а в пайплайні тести плавають. Перед тим як накидати ретраїв, варто подивитися, скільки воркерів одночасно б'ють в один ендпоінт і чи є в відповіді Retry-After — його значення і є правильною паузою.

Кейс 2. Playwright: асерт контракту, а не «щось повернулося»

Створення ресурсу і редирект — два місця, де слабкий асерт роками виглядає зеленим і нічого не перевіряє. Почнемо зі створення: контракт тут не лише про код, а й про адресу нового обʼєкта.

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

test('POST /api/users віддає 201 і адресу створеного ресурсу', async ({ request }) => {
  const res = await request.post('/api/users', {
    // унікальна пошта: фіксоване значення дасть 409 на другому прогоні
    data: { name: 'Ada', email: `ada+${Date.now()}@example.com` },
  });

  expect(res.status()).toBe(201);

  const location = res.headers()['location'];
  expect(location, 'без Location клієнту нема звідки взяти адресу створеного обʼєкта').toBeTruthy();

  // адреса з Location має вести на реально створений ресурс
  const created = await request.get(location);
  expect(created.status()).toBe(200);
});

Редирект перевіряють так само явно — інакше клієнт піде за ним сам і покаже фінальний 200, приховавши всю ланку.

test('стара адреса звіту постійно переїхала на нову', async ({ request }) => {
  // нуль редиректів: клієнт зупиняється й віддає нам саму проміжну відповідь
  const res = await request.get('/legacy/report', { maxRedirects: 0 });

  expect(res.status(), 'переїзд постійний, отже 301, а не 302').toBe(301);
  expect(res.headers()['location']).toBe('/reports/summary');
});

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

• expect(200) на створення — крихкий асерт. Він упаде того дня, коли бекенд почне чесно віддавати 201, і це буде падіння тесту, а не регресія продукту. Дзеркально: якщо API віддає 200 там, де створює ресурс, це претензія до контракту, і її варто озвучити, а не підлаштувати тест.
• 204 не парсять. Якщо ендпоінт за контрактом віддає успіх без тіла, спроба розібрати JSON зробить із зеленого сценарію фальшиве падіння. Спершу статус, потім тіло — і лише якщо воно взагалі передбачене.
• Фінальний 200 нічого не каже про ланцюг. Автопрямування зручне саме тим, чим і небезпечне: зламана проміжна ланка залишається невидимою. Вимкнене автопрямування плюс асерт на Location перетворює редирект на перевірюваний контракт.
• POST через 301 втрачає тіло. Якщо в ланцюзі є редирект, а метод має лишитися незмінним, у контракті мають стояти 307 або 308. Побачили 301 на POST — це не «дивна поведінка клієнта», а закладена специфікацією можливість підмінити метод на GET.
• У UI-тестах ланцюг редиректів ловити не варто взагалі. Проміжний URL (сторінка логіну й назад) існує мить, і очікування на нього — готовий флак. Чекати треба на фінальний стан сторінки, а самі коди перевіряти на рівні API.

Кейс 3. Негативний тест прав: 401, 403 і чесний 404

Найпоширеніша помилка в тестах доступу — прибити асерт рівно до 403. Специфікація дозволяє серверу приховати існування ресурсу під 404, тож такий тест червоніє від зміни політики приватності, а не від дефекту.

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

// сервер має право не розкривати існування чужого ресурсу
const DENIED = [403, 404];
const readerToken = process.env.READER_TOKEN as string;

test('читач не дістає чужий рахунок', async ({ request }) => {
  const res = await request.get('/api/accounts/999', {
    headers: { Authorization: `Bearer ${readerToken}` },
  });

  expect(DENIED).toContain(res.status());
});

test('без облікових даних приходить 401, а не 403', async ({ request }) => {
  const res = await request.get('/api/accounts/999');

  expect(res.status()).toBe(401);
  // за каноном 401 мусить нести цей заголовок; на практиці вимогу часто порушують
  expect(res.headers()['www-authenticate']).toBeTruthy();
});

Коли 404 прилетів там, де його не чекали, помилка — одразу заводити баг. Спершу три питання, і кожне має дешеву перевірку.

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

• 401 і 403 не взаємозамінні в асерті. Перший означає «не впізнав» і лікується логіном, другий — «впізнав і відмовляю», і повторний вхід нічого не змінить. Тест, який приймає обидва коди «про всяк випадок», перестає ловити регресію автентифікації.
• 403 не доводить, що справа в ролі. Заборона могла прийти з причин, ніяк не повʼязаних з обліковими даними, — стан обʼєкта чи правило на посереднику. Формулювання дефекту «користувачу не вистачає прав» тут треба спершу підтвердити, а не припустити.
• 405 — безкоштовний детектор живого маршруту. Він приходить, коли адреса правильна, а метод ресурс не підтримує; отже сама адреса існує. Це найшвидший спосіб відсікти першу з трьох гіпотез про 404.
• Регістр у шляху має значення. Схема й хост до нього нечутливі, а шлях і рядок запиту — чутливі, тож /api/Users/42 цілком законно віддасть 404 там, де /api/users/42 працює.

Клас коду і контракт

• Можу назвати всі пʼять класів і сказати, якої дії кожен вимагає від клієнта, не заглядаючи в довідник.
• Знаю різницю 4xx vs 5xx як межу відповідальності: «правити запит» проти «зламався сервер».
• Розумію, чому асертити треба число, а не пояснювальну фразу поруч: вона необовʼязкова, клієнт не має на неї спиратися, а в HTTP/2 статус несе :status.
• Можу пояснити, чому 500 на завідомо кривому вводі — самостійна знахідка, а не очікуваний результат негативного тесту.

Успіх, тіло відповіді й метод

• Знаю різницю 200 vs 201 і те, що адресу створеного ресурсу за домовленістю кладуть у Location.
• Розумію, чому прибитий expect(200) на створення — крихкий асерт, а не строгіша перевірка.
• Можу назвати три випадки, коли тіла у відповіді немає штатно: HEAD (тут це заборона), 204, 304.
• Знаю різницю 405 vs 415: перший про метод, якого ресурс не підтримує, другий про формат вмісту — і що на кривий Content-Type канонічний саме 415.

Помилки клієнта: 400, 422, 409, 429

• Можу розвести 400 vs 422: зламаний синтаксис проти коректно зібраного, але семантично неможливого запиту.
• Знаю, що 409 — конфлікт із поточним станом ресурсу (зайнятий email, дублікат, конкурентне редагування), а не проблема форми чи змісту самого запиту.
• Можу пояснити, як 429 перетворює паралельний пайплайн на флак і чому лікують його Retry-After та паралелізмом, а не таймаутами.

Доступ: 401, 403, 407 і OAuth

• Знаю різницю 401 vs 403 («хто ти» проти «тобі можна»), памʼятаю про обовʼязковий WWW-Authenticate і тримаю в голові межу ISTQB: автентифікація — процедура, авторизація — наданий дозвіл.
• Розумію, чому 403 не доводить брак ролі, чому сервер має право віддати замість нього 404 і чому негативний тест прав має допускати обидва коди.
• Не плутаю 407 із 401: перший приходить від проксі з парою Proxy-Authenticate та Proxy-Authorization, тобто веде в мережеву конфігурацію, а не в код застосунку.
• Знаю дві особливості кодів у делегованому доступі: 401 буває штатним сигналом оновити токен через refresh, а заголовок Authorization знімається на крос-оріджин редиректі.

Редиректи 3xx і 304

• Знаю дві осі всередині 3xx: постійність (301/308 проти 302/307) і збереження методу з тілом (307/308 проти 301/302).
• Можу відповісти, що станеться з POST при 301, і памʼятаю, що клієнти йдуть за редиректом самі (помітний виняток — curl без -L), тож у тесті видно лише фінальний 200.
• Можу пояснити, що 304 ініціює клієнт умовним запитом із валідатором і що копія в цей момент валідна, а не застаріла.

404 і серверні коди

• Можу розвести ресурс і ендпоінт, знаю три ситуації під одним 404 (немає маршруту, немає обʼєкта, схована заборона) і памʼятаю, що регістр байдужий схемі й хосту, але не шляху.
• Можу пояснити, чому 502 і 504 віддає посередник, а 503 — сам сервіс, і чому масові 5xx відразу за релізом спершу перевіряють як стан середовища.