REST API та формати даних

Що таке REST і чи є він стандартом?

REST — архітектурний стиль, а не протокол і не специфікація, яку можна «підтримувати галочкою». Його сформулював Рой Філдінг (Roy Fielding) у дисертації 2000 року як набір обмежень на взаємодію компонентів розподіленої гіпермедійної системи; система, що їх виконує, зветься RESTful. Обмежень шість: client-server, stateless, cache, uniform interface, layered system і code on demand — останнє єдине необовʼязкове. Найцінніша частина відповіді йде далі за перелік: у жодному з обмежень не сказано ані слова про формат даних. Тому API може віддавати ідеальний JSON і не бути RESTful, а RESTful-система має право обмінюватися чим завгодно. На практиці HATEOAS реалізують рідко, тож обережніше називати такі системи HTTP-API у стилі REST і не сперечатися про чистоту.

Чим ресурс відрізняється від ендпоінта?

Ресурс — це «що», ендпоінт — «де». Ресурсом у REST може бути будь-що, чому дають імʼя: документ, картинка, послуга, колекція, навіть жива людина. Важлива тонкість означення: ресурс — це концептуальне відображення на набір сутностей, а не конкретна сутність у конкретну секунду. Ендпоінт — просто адреса, за якою до цього ресурсу стукають. Третє поняття, яке зазвичай злипається з двома попередніми, — представлення (representation): байти плюс метадані, що описують поточний або бажаний стан ресурсу. Звідси проста перевірка розуміння: JSON у тілі відповіді — це представлення, а не ресурс, і за тією самою адресою завтра прийдуть інші байти, хоча ресурс лишиться тим самим.

Із чого складається запит і відповідь і чи завжди на запит приходить рівно одна відповідь?

Запит — це метод, шлях, заголовки й необовʼязкове тіло; відповідь — статус-код, заголовки й необовʼязкове тіло. Формула «на запит — відповідь» справджується строго лише для фінальної відповіді: перед нею сервер має право надіслати нуль або більше проміжних повідомлень класу 1xx, а завершальна після них буде рівно одна. Ще одна корисна властивість: семантика повідомлення не залежить від версії протоколу, тож посередник може ретранслювати запит між HTTP/1.1 і HTTP/2, не змінюючи його змісту. Для QA з цього випливає практичний висновок: вердиктом про обробку є статус саме фінальної відповіді, а не проміжних 1xx. А ще памʼятайте про обмеження layered system: між вами й застосунком цілком легально стоять проксі, балансувальники та CDN, тож відповідь інколи формує зовсім не той вузол, який ви тестуєте.

Що означає stateless і як тоді взагалі існує сесія користувача?

Безстановість означає, що кожен запит несе все потрібне для свого розуміння, а сервер не має права спиратися на памʼять про попередні звернення — навіть два запити в одному зʼєднанні він не зобовʼязаний вважати запитами того самого агента. Мотив суто інженерний: якщо сервер нічого не памʼятає, будь-який вузол із десятка однакових обробить будь-який запит, а система моніторингу зрозуміє природу запиту з нього самого. «Памʼять» тому будують поверх протоколу двома способами: кукі, яку сервер видає заголовком Set-Cookie і яку агент користувача сам повертає в Cookie, і токен, який їде в заголовку Authorization у формі Bearer. Різниця для тесту принципова: кукі доїде автоматично, а токен покладе тільки той код, який ви написали. Найдешевший практичний наслідок: сесію для сценарію отримують одним API-викликом і підкладають у контекст, замість проклацувати форму входу в кожному тесті.

Які частини URL доїжджають до сервера, а які ні?

Сервер отримує authority, шлях і рядок запиту; фрагмент після # відсікається ще на клієнті й у логах API не зʼявляється ніколи — його обробляє винятково клієнт. Друга частина відповіді про регістр: схема й хост нечутливі до нього й нормалізуються в нижній, а шлях і рядок запиту вважаються чутливими, якщо схема не сказала іншого. Саме тому склеєний із тестових даних /api/Users/42 може дати 404 там, де /api/users/42 працює. Третя деталь: типовий порт особливої схеми в серіалізації опускають, тож адреси з :443 і без нього для https тотожні. І четверта: структуру самого рядка запиту стандарт не регламентує зовсім — пари ключ=значення через & є домовленістю, успадкованою від HTML-форм, тому поведінка при дублюванні параметра залежить від конкретного бекенда, а не від стандарту.

Що таке відсоткове кодування і чому одна українська літера дає дві трійки?

Це спосіб подати байт трьома символами: знак відсотка й дві шістнадцяткові цифри його значення. Працює воно у два кроки, і саме тут інтуїція підводить: спершу текст стає послідовністю байтів (у вебі це майже завжди UTF-8), і аж потім кожен байт окремо переписується як %XX. Тому пробіл дає одну трійку %20, а українська «і» в UTF-8 займає два байти й перетворюється на %D1%96. Кодування потрібне там, де символ не належить до дозволеного набору або де він працює роздільником; натомість латинські літери й цифри разом із чотирма символами — дефісом, крапкою, підкресленням і тильдою — належать до незарезервованих і лишаються як є. Дві дрібниці для сильної відповіді: шістнадцяткові цифри регістронезалежні, тож %2F і %2f — те саме, а набір символів, які підлягають кодуванню, залежить від того, у якому компоненті адреси вони стоять.

У логах видно ?q=search+results. Це пробіл чи плюс?

Залежить від угоди, у якій зібрано рядок. У форматі application/x-www-form-urlencoded пробіл записують плюсом, а сам плюс доводиться екранувати як %2B; у шляху ж цей символ означає буквальний плюс. Ті самі граблі живуть у коді тесту: encodeURIComponent віддасть для пробілу %20 і закодує амперсанд, URLSearchParams для того самого пробілу дасть +, а encodeURI роздільники адреси лишає недоторканими, бо створений для вже зібраного URL цілком. Окреме динамічне значення тому кодують саме через encodeURIComponent. Практичний висновок дешевий: асерт будуйте на декодованих значеннях — інакше два записи того самого фільтра, ?q=search+results і ?q=search%20results, розійдуться в порівнянні, хоча дані за ними ідентичні.

Чим PUT відрізняється від PATCH?

Обидва змінюють ресурс, але різняться тим, чим є тіло запиту. У PUT тіло — це нова версія ресурсу цілком: сервер створює його або повністю замінює поточний стан переданим. У PATCH тіло — набір інструкцій, як саме змінити те, що вже лежить на сервері, тобто часткова зміна. Звідси й різні властивості: PUT ідемпотентний, бо десять однакових замін дають той самий кінцевий стан, а PATCH за специфікацією не є ані безпечним, ані ідемпотентним. Класична пастка тут — надіслати в PUT тільки одне змінене поле: формально це заміна всього ресурсу, і решта полів може легально обнулитися. Окремо варто знати, що конкретний PATCH можна зробити ідемпотентним умовним запитом — наприклад, зі строгим ETag в If-Match, — щоб два паралельні патчі не затерли один одного.

Які методи безпечні, а які ідемпотентні? POST ідемпотентний?

Безпечний метод — той, чия семантика зводиться до читання: клієнт не просить змінювати стан на сервері. Такими є GET, HEAD, OPTIONS і TRACE. Ідемпотентний — той, для якого повторення того самого запиту дає рівно той самий намірений результат, що й одна спроба: це PUT, DELETE і всі безпечні методи. POST не є ані безпечним, ані ідемпотентним, як і PATCH та CONNECT. Два уточнення, за які дають бали: усі безпечні методи ідемпотентні, але не навпаки, а сама безпечність не обіцяє повної відсутності побічних ефектів — сервер має право дописати рядок у лог доступу, і це нічого не порушує, бо такого запису клієнт не замовляв. І третя, окрема вісь — кешованість: за замовчуванням кешованими вважаються тільки GET і HEAD, тож зі згаданими двома властивостями вона не збігається.

DELETE повторили — прийшов 404. Це порушення ідемпотентності?

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

У чому різниця між 400 і 422, 401 і 403?

Це дві пари, які закривають половину негативних сценаріїв, і обидві розводяться однією фразою. 400 проти 422: «я не зрозумів, що ти надіслав» проти «я все розібрав, але так не можна» — тобто зламаний синтаксис проти коректно зібраного запиту з неможливим змістом. 401 проти 403: «не знаю, хто ти» проти «знаю, але тобі не можна» — брак автентифікації проти відмови в доступі вже впізнаному клієнту. Дві деталі підвищують оцінку: відповідь 401 мусить нести заголовок WWW-Authenticate, а повторний логін при 403 нічого не змінить, бо стадію впізнавання вже пройдено. І окремо памʼятайте межу класів: на сміттєвий ввід зріла реалізація має відповідати кодом класу 4xx, а 500 у відповідь на такий запит — самостійна знахідка, а не очікуваний результат негативного тесту.

Що буде, якщо надіслати JSON із заголовком Content-Type: application/x-www-form-urlencoded?

Канонічна відповідь сервера — 415 Unsupported Media Type: специфікація прямо називає причиною цього коду непідтримуваний Content-Type або Content-Encoding запиту. На практиці частина бекендів віддає загальний 400 — це менш точно: 400 описує будь-яку помилку клієнта, а не відмову саме через формат тіла. Сильна відповідь на співбесіді називає обидва варіанти й додає, що в баг-репорті різницю варто зафіксувати. Причина такої ситуації майже завжди одна — заголовок не збігається з тим, що реально поїхало в тілі, і це найпоширеніше джерело «у браузері працює, а в тесті ні». Тому перед заведенням дефекту звіряють оголошений тип із фактичним тілом запиту, а не з очікуваннями.

Які три формати тіла QA бачить щодня і навіщо в multipart потрібен boundary?

Перший — application/json: вкладені обʼєкти й масиви з типами, дефолт сучасних HTTP-API. Другий — application/x-www-form-urlencoded: плоскі пари, зʼєднані амперсандом, зі спецсимволами у відсотковому кодуванні й пробілом у вигляді плюса; історично це те, що шле HTML-форма. Третій — multipart/form-data: тіло, розрізане на частини, кожна зі своїми міні-заголовками; саме ним відправляють файли. boundary тут — оголошений у Content-Type рядок-роздільник: частини відокремлює два дефіси плюс його значення, а фінальний роздільник має ще два дефіси в кінці. Головна вимога — значення не повинно трапитися всередині самого вмісту, інакше тіло розпадеться не там, де треба. Практичний висновок: multipart не складають руками, а передають файл обʼєктом і дають клієнтській бібліотеці зібрати тіло й заголовки самій.

З чого складається чесний асерт на відповідь API і чому не порівнюють усе тіло цілком?

Мінімальний чесний асерт має три частини: статус-код, Content-Type і структура тіла. Перевірка лише статусу дає хибно-зелений результат — реальний антипатерн 200 OK з тілом на кшталт помилки «не знайдено» проходить такий тест без жодного зауваження. Перевірка лише тіла теж неповна: без Content-Type ви не знаєте, чи мали право його парсити. А от порівнювати відповідь на повну рівність із еталоном — крихкий підхід: у межах однієї версії API поля прийнято додавати, і безпечне розширення відповіді ламатиме такий асерт щоразу. Правильна стратегія — толерантний читач: перевіряти саме ту підмножину полів, від якої залежить сценарій. І окремо: гарантій на послідовність ключів в обʼєкті не було ніколи, тож будь-який асерт, що на неї спирається, ненадійний за побудовою.

Які типи значень є в JSON і чого в ньому немає?

Простих типів чотири — рядок, число, булеве значення й null; структурних два — обʼєкт і масив; разом шість, і нічого понад це формат не має. Медіа-тип — application/json, а для обміну поза замкнутою екосистемою документ має бути закодований у UTF-8. Друга половина відповіді цінується більше за першу: у JSON немає типу «дата», немає коментарів і немає поділу чисел на цілі й дробові — число одне, а провідні нулі заборонені. Дату тому везуть або рядком за RFC 3339 / ISO 8601, або числом, а домовленість про її форму стає частиною контракту й перевіряється окремим асертом. Рядок береться лише в подвійні лапки, лапки й зворотну скісну риску всередині екранують, а літерали true, false і null пишуться малими. Те, чого формат не має, команди домовляють окремо — і перевірка саме таких домовленостей лягає на тест.

Чи можна покладатися на порядок ключів і чи впаде парсер на дублікатах?

На порядок ключів — ні: специфікація прямо називає обʼєкт невпорядкованою колекцією, тоді як масив упорядкований. Тобто послідовність елементів масиву значуща й перевіряти її можна, а асерт на послідовність полів обʼєкта ненадійний за побудовою. З дублікатами ситуація ще підступніша: унікальність імен у JSON — рекомендація, а не вимога, тож документ із двома однаковими ключами лишається валідним. Поведінка приймача в такому разі не визначена, а на практиці більшість реалізацій бере останню пару. Висновок для роботи прямий: дублікат ключа не підсвітить ані парсер, ані тип-чекер — його ловить лише тест, який дивиться на сирий текст відповіді або на схему.

Чим null відрізняється від відсутнього поля і чому це дорого коштує?

null у JSON — це повноцінне значення, одне з шести типів, а не спосіб сказати «поля немає». Тому обʼєкт із полем у значенні null і обʼєкт без цього поля описують два різні контракти: у першому випадку бекенд стверджує «значення відоме й воно порожнє», у другому — «даних про це немає взагалі». Асерт «поле присутнє» і асерт «поле не порожнє» перевіряють різні речі, і підміна одного одним дає або хибно-зелений тест, або нескінченні розслідування на порожньому місці. У коді тесту різниця теж має ціну: властивість зі значенням undefined при серіалізації просто зникне з обʼєкта, тобто ви надішлете не те, що думали. Тому в контракті на поле, яке може бути порожнім, завжди уточнюють, що саме приходить, — null чи відсутність ключа.

Що JSON.stringify() робить із Date і undefined?

Обидва випадки — типове джерело «я ж передав правильні дані». У Date є власний метод toJSON(), і його результат збігається з тим, що віддає toISOString(); у тіло запиту потрапляє саме цей рядок, тож зворотний розбір відповіді обʼєкт дати вже не відновить. Зі значеннями undefined поведінка асиметрична: в обʼєкті ключ із таким значенням до результату не потрапляє взагалі, а в масиві на його місці зʼявляється null, тож довжина масиву лишається колишньою. Є й третій, найнеприємніший варіант: серіалізація може повернути не рядок, а undefined, і тоді тіло запиту виявиться порожнім. Сервер на таке відповість 400, і на перший погляд винним виглядатиме він, хоча зламався клієнтський код. Тому при розслідуванні 400 спершу дивляться на фактично надіслане тіло в панелі Network, а не на те, що збирався надіслати код.

Тест падає на розборі JSON. З чого починати діагностику?

З перевірки того, чи взагалі там був JSON. Для парсера порожнє тіло, HTML-сторінка помилки від шлюзу й обірваний потік — однаково невалідний вхід, і виняток у стектрейсі маскує справжню причину: ви шукатимете дефект у форматі даних замість того, щоб побачити 502 у статусі. Тому порядок дій у тесті зворотний до інтуїтивного: спершу статус, потім Content-Type, і лише після цього розбір тіла. Другий частий сценарій — відповідь, у якої тіла немає за контрактом: 204 No Content парсити нічого, і падіння тут означає помилку в тесті, а не в застосунку. Третій — проксі чи балансувальник, що повернув свою власну сторінку помилки з типом text/html; це видно за одним поглядом на заголовок відповіді.

Чому в gRPC статус 200 нічого не каже про успіх виклику?

Тому що gRPC використовує HTTP/2 як транспорт, а власний результат передає окремо. Кожен виклик на дроті — це POST із Content-Type, що починається з application/grpc; на чужий тип сервер має відповісти 415. І успіх, і помилка приходять зі :status 200, а справжній код операції лежить у трейлері grpc-status — тому звичний рефлекс «двісті, отже все добре» тут не працює. Друга особливість — дані серіалізує Protocol Buffers, платформо-нейтральний механізм, який у gRPC стоїть за замовчуванням, але не є його невідʼємною частиною. Практичні наслідки два: у мережевій панелі тіло такого виклику JSON-ом не прочитається, а порівнювати два повідомлення байт у байт безглуздо — одні й ті самі дані мають безліч валідних бінарних форм.

Три кейси, у яких модель «ресурс — метод — статус — тіло» перетворюється на конкретні дії: розбір скарги «кнопка не працює» за одним записом у панелі Network, асерт контракту в Playwright, який не бреше і не сиплеться від сумісних змін, і рішення про ретрай після таймауту в CI.

Кейс 1. «Зберегти не працює»: розбір однієї відповіді за три шари

Скарга приходить у вигляді «нічого не зберігається». Замість здогадок беремо один запис у панелі Network і читаємо його трьома шарами: спершу статус (чия це проблема), потім Content-Type (чи маю я право парсити тіло), потім саме тіло (що конкретно не так). Три шари дають вердикт швидше, ніж будь-який лог.

Що тут найчастіше плутають:

• 415 виглядає як 400, а означає інше. Загальний 400 каже «я не розібрав запит», тоді як 415 називає причину точно: непідтримуваний Content-Type або Content-Encoding. Побачили 415 — не поспішайте до бекенду, спершу гляньте, чим ваш клієнт підписав тіло.
• 404 на живому ендпоінті — не завжди «немає обʼєкта». Регістр у схемі й хості значення не має, а от у шляху й рядку запиту має, тож /api/v1/Users/42 законно промахнеться там, де працює /api/v1/users/42. Відрізнити одне від одного допомагає той самий шлях іншим методом: 405 означає, що ресурс за адресою є, просто цього методу він не підтримує.
• Фрагмента адреси в логах API не буде ніколи. Усе після # обробляє клієнт і на сервер не надсилає. Тому шукати причину «сервер не бачить мій параметр» у фрагменті марно — параметри живуть у рядку запиту.
• Відповідь міг сформувати не застосунок. Між клієнтом і бекендом легально стоять проксі, балансувальники й CDN, і сторінка помилки з типом text/html замість очікуваного JSON — типовий підпис такого посередника.

Кейс 2. Playwright: асерт, який не бреше і не сиплеться

Дві крайності однаково погані. Асерт лише на статус пропускає 200 із тілом-помилкою; асерт на повну рівність тіла червоніє щоразу, коли бекенд додає нове поле — а додавання полів у межах версії вважається сумісною зміною. Робоча середина — три шари з першого кейсу плюс перевірка тієї підмножини даних, від якої залежить сценарій.

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

test('GET /api/v1/users/42 віддає контракт користувача', async ({ request }) => {
  const res = await request.get('/api/v1/users/42');

  // 1. статус: вердикт про обробку
  expect(res.status()).toBe(200);

  // 2. тип вмісту: підстава взагалі парсити тіло
  expect(res.headers()['content-type']).toContain('application/json');

  // 3. структура: лише те, від чого залежить сценарій
  const user = await res.json();
  expect(user).toMatchObject({ id: 42, name: 'Alice' });
  expect(user.roles).toContain('qa');

  // null і відсутність ключа — різні контракти, тому перевіряємо саме те, що обіцяно
  expect(user).toHaveProperty('phone');
  expect(user.phone).toBeNull();

  // дати в JSON немає: приходить рядок, і його формат — частина контракту
  expect(typeof user.createdAt).toBe('string');
});

Створення ресурсу перевіряють тим самим шаблоном, але тіло формує клієнт — і саме тут ламаються заголовки.

test('POST /api/v1/orders створює замовлення', async ({ request }) => {
  // data → application/json проставить сам клієнт; руками заголовок не чіпаємо
  const res = await request.post('/api/v1/orders', {
    data: { sku: 'A-100', qty: 2 },
  });

  expect(res.status()).toBe(201);
  expect(res.headers()['location']).toBeTruthy();
});

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

• Порядок кроків не косметичний. Розбір тіла — окрема операція, яка падає на будь-якому невалідному вході: порожня відповідь, HTML від шлюзу, обірваний потік. Виняток у парсері маскує справжню причину, і ви шукаєте баг у форматі даних замість того, щоб побачити 502 у статусі.
• 204 не парсять взагалі. Якщо ендпоінт за контрактом віддає успіх без тіла, спроба дістати з нього JSON перетворить зелений сценарій на фальшиве падіння.
• Порядок ключів перевіряти не можна, порядок елементів масиву — можна. Обʼєкт у JSON невпорядкований за специфікацією, масив упорядкований; асерт на послідовність полів ненадійний за побудовою.
• Дублікат ключа у відповіді парсер не підсвітить. Унікальність імен у JSON — рекомендація, документ із дублями лишається валідним, а більшість реалізацій мовчки бере останню пару. Хочете це ловити — дивіться на сирий текст відповіді або на схему.
• Порівнюйте декодовані значення параметрів, а не сирі рядки. ?q=search+results і ?q=search%20results несуть однакові дані, але побайтово не збігаються: у формі application/x-www-form-urlencoded пробіл записують плюсом, тоді як encodeURIComponent віддає %20.
• Date у тілі запиту стає рядком. Серіалізація викликає toJSON(), тож на сервер їде текст у форматі ISO, і зворотний розбір відповіді обʼєкт дати не відновить. А поле зі значенням undefined при серіалізації просто зникне з обʼєкта — і сервер отримає не те, що ви збиралися надіслати.

Кейс 3. Таймаут у CI: що можна повторити, а що лишить привида

Мережа моргнула, клієнт не дочекався відповіді, тест упав. Спокуса очевидна — обгорнути все ретраєм. Але повторний запит безпечний рівно там, де метод ідемпотентний: скільки б разів ви не відправили той самий запит, намірений результат буде такий, як після однієї спроби. Ідемпотентність описує стан сервера, а не однаковість відповідей — це те місце, де плутанина коштує найдорожче.

Найбільша шкода від наївного повтору POST не в самому дублікаті, а в тому, де він вистрелить: другий обʼєкт спокійно доживе до наступного тесту й зламає його асерт на кількість записів. Причину такого падіння шукають у зовсім іншому файлі, ніж та, що її створила.

Прибирання пишуть із урахуванням того, що DELETE ідемпотентний, а коди двох викликів різні:

test.afterEach(async ({ request }) => {
  const res = await request.delete(`/api/v1/orders/${orderId}`);

  // 404 на другому проході — норма: стан сервера вже потрібний, обʼєкта немає
  expect([204, 404]).toContain(res.status());
});

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

• Ідемпотентність — не про тіло відповіді. Перший DELETE віддасть 204, повторний — 404, і це не порушення властивості: стан системи в обох випадках однаковий. Асерт, прибитий рівно до 204, зробить прибиральник ламким.
• PATCH не рятує «бо це ж оновлення». Специфікація прямо каже, що він ані безпечний, ані ідемпотентний. Якщо повтор потрібен, конкретний запит роблять умовним — зі строгим ETag в If-Match, — і два паралельні патчі перестають затирати один одного.
• Кешованість — окрема вісь. Те, що метод безпечний, не робить його відповідь кешованою автоматично: за замовчуванням кешованими вважаються лише GET і HEAD. Плутати ці властивості — типова помилка на співбесіді.
• GET, який щось змінює, — дефект контракту. Протокол описує наміри, а не гарантує поведінку реалізації, тож технічно такий ендпоінт можливий. Знайшли — це баг, а не «особливість нашого API», і ретраї на ньому небезпечні попри «безпечний» метод.

REST як стиль, а не формат

• Можу назвати автора, рік і природу REST: архітектурний стиль, а не протокол чи стандарт із сертифікацією відповідності.
• Памʼятаю всі шість обмежень і те, яке з них єдине необовʼязкове (code on demand).
• Розумію, чому «REST — це JSON поверх HTTP» хибна формула: формат серіалізації до стилю не належить узагалі.

Безстановість і стан у тесті

• Можу пояснити stateless через самодостатність запиту й назвати мотив — масштабованість плюс видимість запиту для моніторингу.
• Знаю різницю кукі vs токен за способом доставки: одну повертає агент користувача сам, другий кладе лише код застосунку — тому сесію для сценарію дешевше готувати одним API-викликом.

Ресурс, ендпоінт, адреса

• Знаю різницю ресурс vs ендпоінт vs представлення: «що», «де» і «в якому вигляді» — і можу пояснити, чому вміст за адресою змінюється, а сам ресурс лишається тим самим.
• Памʼятаю, які частини URL їдуть на сервер, а що відсікається на клієнті (фрагмент), і де регістр значущий: шлях і рядок запиту, але не схема з хостом.
• Знаю різницю %20 vs + у application/x-www-form-urlencoded і розумію, чому одна українська літера дає дві трійки: текст спершу стає байтами UTF-8, і кожен байт кодується окремо.

Методи та їхні властивості

• Можу назвати обидва переліки напамʼять: безпечні — GET, HEAD, OPTIONS, TRACE; ідемпотентні — PUT, DELETE плюс усі безпечні; кешованість за замовчуванням — третя, окрема вісь і лише для GET та HEAD.
• Знаю різницю PUT vs PATCH за вмістом тіла: нова версія ресурсу проти набору інструкцій зі зміни.
• Можу відповісти, чому DELETE із 404 на другому виклику не порушує ідемпотентності, і знаю, які запити безпечно повторювати після таймауту, а де наївний ретрай POST лишить у базі привида.

Статус-код і контракт відповіді

• Можу розвести дві пари одним рядком: 400 vs 422 і 401 vs 403.
• Знаю, що канонічна відповідь на невідповідний Content-Type — 415, а не 400, і можу це аргументувати в баг-репорті.
• Тримаю порядок перевірки відповіді: статус, Content-Type, і лише потім структура тіла — і памʼятаю, чим небезпечний 200 із тілом-помилкою.

Тіло, формати, JSON

• Знаю три щоденні формати тіла й те, чим boundary тримає купи multipart/form-data.
• Можу перелічити шість типів JSON і, що важливіше, назвати чого в ньому немає: дат, коментарів, поділу чисел на цілі й дробові.
• Знаю різницю null vs відсутнє поле: це два різні контракти, а не синоніми.
• Памʼятаю, що обʼєкт невпорядкований, а масив упорядкований, і що дублікат ключа лишає документ валідним — ловить його тест, а не парсер.
• Розумію, чому асерт на рівність усього тіла крихкий: додавання полів — сумісна зміна, тому перевіряю потрібну підмножину.
• Можу пояснити, що JSON.stringify() робить із Date і undefined і чому через це тіло запиту інколи їде порожнім.