HTTP: методи, структура, заголовки

З яких частин складається HTTP-повідомлення?

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

Що таке метод і які властивості його описують?

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

Що означає «безпечний метод»?

Безпечність описує семантику «лише читання» з погляду клієнта: надсилаючи такий запит, він не замовляє зміну стану на сервері й не розраховує на неї. Формулювання «без побічних ефектів» — зручне спрощення, але неточне, бо реалізації прямо дозволено робити щось стороннє й під таким методом — за приклад специфікація бере запис у журнал звернень. Різниця в тому, хто відповідальний: побічний ефект є, але клієнт його не просив і не мусить за нього відповідати. Задум поділу теж названо прямо — щоб краулери й префетч у браузері могли ходити такими адресами, нічого не ламаючи. Звідси й головна практична межа: безпечність — це обіцянка контракту, а не властивість конкретного коду на бекенді.

Чому GET, який видаляє запис, — це баг, а не особливість реалізації?

Тому що протокол фіксує наміри, а не гарантує поведінку реалізації: технічно ніщо не заважає повісити видалення на GET /users/42/delete, і сервер це виконає. Проблема в тому, що весь світ довкола покладається на обіцянку безпечності. Пошуковий робот обійде посилання, браузер попередньо завантажить його, антивірусний проксі чи превʼю в месенджері смикнуть адресу — і запис зникне без жодного наміру шкодити. Тому правильна реакція QA — завести баг контракту, а не підлаштовувати тест під наявну поведінку. У баг-репорті варто писати не «незвична реалізація», а конкретний ризик: дію зі зміною стану може викликати будь-хто, хто просто побачив адресу.

Що таке ідемпотентність і які методи ідемпотентні?

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

DELETE вдруге повертає 404. Він же тоді не ідемпотентний?

Ідемпотентний, і це класична підміна понять. Властивість описує ефект на сервері, а не однаковість відповідей: коди й заголовки повторних викликів можуть відрізнятися скільки завгодно. Перший DELETE прибирає ресурс і віддає 200 чи 204, другий уже не має що прибирати й віддає 404 — але стан у момент після першого й після другого виклику однаковий: ресурсу немає. Для автотесту з цього випливає конкретна вимога до асерту: сценарій повторного видалення має очікувати саме таку пару кодів, а не трактувати 404 як порушення. І дзеркально — асерт «повтор дає той самий код, що й перший виклик» тут зайвий і зробить тест ламким без жодної користі.

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

PUT створює ресурс або цілком замінює його переданим поданням, PATCH застосовує часткову зміну. Різницю видно в тілі: у PUT ви шлете змінену версію ресурсу, у PATCH — набір інструкцій, що з ним зробити. Звідси головний ризик, заради якого це й питають: неповний PUT затирає все, чого ви не передали, тож оновлення однієї ролі повним заміщенням легко знесе решту полів обʼєкта. Формат тіла PATCH одним стандартом не закріплений — існують application/json-patch+json і application/merge-patch+json, але чимало API приймають власний частковий JSON, тому припускати формат не можна, треба дивитися контракт. Хороший негативний тест на PUT перевіряє рівно це: надсилаємо подання без частини полів і дивимось, що станеться з ними в базі.

Чи можна вважати PATCH ідемпотентним, якщо тіло щоразу однакове?

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

Навіщо існує HEAD і де на ньому спотикаються автотести?

HEAD — це GET без вмісту: запит іде за тією ж адресою, але надсилати тіло у відповідь серверу заборонено нормативно. Цінність у дешевизні — можна перевірити, що ресурс існує, що посилання не побите, що файл доступний, не витягуючи мегабайти. Заголовки сервер має віддати ті самі, що й на GET, але з важливим застереженням: поля, значення яких зʼявляється лише при генерації вмісту, він має право пропустити, і специфікація прямо називає прикладом Content-Length. Ось де пастка: асерт «файл важить рівно стільки-то», побудований на HEAD, може падати через відсутність заголовка, і це буде реалізоване право сервера, а не знахідка. Правильний тест спершу перевіряє наявність поля й лише потім його значення — або взагалі бере розмір із GET.

Звідки в панелі мережі береться OPTIONS, якого код не надсилав?

Це майже завжди CORS preflight. Перед непростим крос-оріджин запитом браузер зобовʼязаний окремо спитати сервер, чи дозволено такий метод і такі заголовки, і робить це саме методом OPTIONS. Тобто «зайвий» рядок перед вашим POST або PATCH — не баг фронтенду й не подвійне надсилання, а обовʼязковий крок протоколу; шукати його в коді застосунку марно. Сам по собі метод має ширше призначення — дізнатися доступні опції взаємодії з ресурсом, нічого над ним не виконуючи. Друга тонкість, за яку дають бали на співбесіді: відповідь OPTIONS — це заявка, а не вердикт, і при перевірці безпеки реальний перелік дозволених методів зʼясовують фактичними запитами, а не довірою до списку.

Чим Content-Type відрізняється від Accept?

Вони дивляться в різні боки в часі. Content-Type описує те, що вже лежить у тілі цього повідомлення, і працює в обидва боки — у запиті характеризує дані клієнта, у відповіді дані сервера. Accept — побажання клієнта щодо формату майбутньої відповіді, частина механізму узгодження вмісту, і живе він переважно в запиті. Побутова мнемоніка: перший каже «ось що я поклав у конверт», другий — «а відповідь надішліть у такому вигляді». У межах одного запиту вони спокійно відрізняються: форма їде як application/x-www-form-urlencoded, а відповідь очікується JSON-ом. Сильна відповідь додає код відмови: якщо серверу не підходить формат тіла, нормативна реакція — 415.

Сервер відповів 400 на тіло в непідтримуваному форматі. Це коректно?

Формально — ні, і це готова знахідка. Коли тіло приїхало у форматі, з яким цей метод на цьому ресурсі не працює, специфікація має для відмови окремий код 415, тоді як 400 означає загальну проблему з запитом. Різниця не академічна: 415 одразу веде клієнта до заголовка Content-Type, а 400 змушує перебирати весь запит — тіло, параметри, довжину, кодування. На практиці бекенди схиблюють тут часто, тож заводити критичний баг не варто, але назвати відступ у репорті слід — це реальна вартість підтримки для команди інтеграції. Для власних негативних тестів висновок такий: очікуваним результатом на кривий Content-Type пишіть 415 і звіряйтеся з контрактом API, а не з поточною поведінкою.

Що означає q=0 у заголовку Accept?

Це відмова, а не «найменш бажаний варіант». Ваги в узгодженні вмісту нормовані в діапазон від нуля до одиниці, за відсутності ваги перевага дорівнює одиниці, а нуль означає, що формат клієнтові неприйнятний узагалі. Найменш бажане з прийнятного позначають 0.001 — саме тому край діапазону варто памʼятати точно. Поруч живе обмеження на форму запису: вагу з чотирма й більше знаками після коми відправникові складати не дозволено. Практичний наслідок для тестів простий — рядок на кшталт Accept: application/json, text/html;q=0 не є способом «злегка знизити пріоритет» HTML, це пряма заборона, і сервер має повне право відповісти відмовою в узгодженні.

Чому схему Basic не можна вважати захистом сама по собі?

Тому що в ній немає нічого, крім кодування. Клієнт склеює логін і пароль через двокрапку, кодує пару в base64 і кладе в Authorization — а base64 розгортається назад будь-ким за секунду, це не шифрування. Специфікація каже це прямо: без захищеного транспорту знизу — TLS — схему вживати не варто, інакше логін і пароль мандрують мережею фактично відкритим текстом. Є ще дрібна деталь, яка регулярно ламає тести: роздільником вважається перша двокрапка, тож двокрапка всередині логіна робить пару невалідною, а всередині пароля — ні. Коли доступ закритий, у відповідь прилітає 401, а схему для входу сервер називає в заголовку WWW-Authenticate; проксі робить те саме своєю парою — 407 і Proxy-Authenticate, і плутати їх не можна, бо це різні місця для пошуку причини.

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

Найімовірніше, ви натрапили на forbidden request-header — перелік полів, якими розпоряджається сам браузер, бо на них тримаються межі безпеки. Туди потрапили Host, Cookie, Referer, Origin, Date, Connection, Content-Length, TE і Transfer-Encoding, а на додачу дві цілі групи — усе з префіксом proxy- і все з префіксом sec-. Код сторінки їх не задає, і обробник маршруту в тесті теж: Playwright прямо каже, що підміну забороненого заголовка буде проігноровано, а запит поїде з оригінальним значенням. Найгірше тут не сама заборона, а те, що вона тиха: помилки немає, тест зеленіє на неперевіреному сценарії. User-Agent у списку немає — саме тому підміна клієнта працює: браузер вставляє власне значення лише тоді, коли в наборі заголовків його ще немає. Практичний висновок: сценарії з чужою роллю через підміну Cookie треба будувати на рівні контексту чи сесії, а не на перехопленні запиту, і обовʼязково мати асерт, який доводить, що підміна справді доїхала.

Що має їхати в рядку запиту, а що тілом?

Межа проходить по трьох речах: структура, видимість і довжина. Query тягне пласкі пари «ключ-значення», лежить прямо в адресі й обмежений, тіло везе довільну структуру — JSON, форму, файли — і має ліміт на порядки більший. Цифри тут реальні: специфікація зверху довжину URL не обмежує, але радить усім підтримувати щонайменше вісім тисяч октетів, і дефолти серверів того самого порядку — Apache ріже стартовий рядок на 8190 байтах, nginx не дає рядку запиту вилізти за буфер із large_client_header_buffers і віддає 414. Ліміт на тіло тим часом вимірюється гігабайтом за замовчуванням. Третій критерій найважливіший для безпеки: усе, що потрапило в адресу, осідає в історії браузера, логах сервера й реферерах, тому секрети й токени їдуть тілом, а токен у query-параметрі — готовий пункт для security-репорту.

Запит відпрацював успішно, але тест падає на розборі JSON. Що сталося?

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

Як влаштоване тіло multipart/form-data і що в ньому найлегше зіпсувати?

Коли у формі є файл, звичайного кодування форми замало, і тіло розбивають на частини. Кожна частина має власні міні-заголовки, а розділяє їх унікальний рядок-роздільник, оголошений параметром boundary у Content-Type; частина з файлом додатково несе filename і власний Content-Type. Механіка проста, але прискіплива: у тілі роздільник записують як два дефіси плюс саме значення, а в останньому до нього дописують ще пару дефісів у кінець. Унікальність — вимога нормативна: цей рядок не має права зустрітися всередині якоїсь із частин, ані сам по собі, ані на початку іншого рядка; сам параметр для multipart обовʼязковий, має від одного до сімдесяти символів і не може завершуватися пробілом. Тому руками таке тіло не складають: у Playwright чи HTTP-клієнті файл передають обʼєктом і дають бібліотеці зібрати конверт самій — інакше налагоджуватимете не застосунок, а власний роздільник.

Що означає «HTTP — безстановий протокол», якщо в застосунку є сесія?

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

Проєкт переїхав на HTTP/2. Що станеться з тестами на методи, коди й заголовки?

Нічого — і саме це головне в питанні. HTTP/2 змінює подання повідомлень, а не їхню семантику: набір методів, статус-кодів і заголовків лишається незмінним, інакшим стає тільки транспортне оформлення. Замість читабельного тексту зʼявляються бінарні кадри, окремого стартового рядка немає взагалі — керівні дані переносять псевдозаголовки з двокрапкою на початку: у запиті це :method, :path, :scheme і :authority, у відповіді — :status. HTTP/3 користується такими самими за призначенням полями й прямо каже про себе, що способу передати номер версії чи пояснювальну фразу зі старого статус-рядка він не визначає. Пастка тут у слові «версія»: HTTP/2 її теж не передає окремим індикатором — специфікація формулює її неявно, «2.0» і для запитів, і для відповідей, — а от пояснювальної фрази вона не згадує жодного разу, тож для HTTP/2 це вивід, а не цитата. Практичних наслідків для QA два: контрактні перевірки методів, кодів і заголовків не переписують, а от асерт, прибитий до тексту пояснювальної фрази, лишається ризиком — і це буде проблема тесту, а не продукту.

Три кейси з робочого життя QA, у яких відповідь дає не код застосунку, а сам запит: чому після мережевого моргання зʼявився другий рахунок, як за пів хвилини прочитати панель мережі по кістках і як перекласти рутину логіну та підготовки даних на заголовки й тіло замість кліків.

Кейс 1. Два замовлення замість одного: хто винен — продукт чи ретрай

Скарга з підтримки: у частини користувачів дублюються замовлення. Відтворити руками не виходить, у логах бекенду видно два повноцінні успішні POST /orders з різницею в кілька секунд і однаковим тілом. Спокуса — завести баг «сервіс створює дублі», але спершу треба відповісти на інше питання: хто надіслав другий запит.

Порядок перевірки простий і майже завжди дає відповідь на другому кроці.

Далі — те, як цей самий поділ визначає, що можна повторювати в тестах і в клієнті.

Три висновки, які варто писати в тікет.

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

Кейс 2. Панель мережі за пів хвилини: сім симптомів і що за ними стоїть

Найдорожчі години в тестуванні втрачаються на баг-репорти про поведінку, яка є нормою протоколу. Ця таблиця — швидкий фільтр перед тим, як заводити тікет.

Що з цього варто винести окремо.

• Розрізняти 401 і 407 — це економія годин, а не педантизм. Перший веде в код автентифікації застосунку, другий — у корпоративну мережу; переплутавши, ви шукатимете токен там, де проблема в проксі.
• «Порожня відповідь» майже ніколи не є багом сервера. 204 і відповідь на HEAD тіла не несуть за правилами, тож розбирати його тут нема чого — очікуваний результат пишіть за контрактом, а не за звичкою «прийшов JSON».
• Асерт на пояснювальну фразу статусу — міна сповільненої дії. Її дозволено ігнорувати, а в HTTP/3 місця під неї немає взагалі: перевіряйте число.

Кейс 3. Заголовки й тіло як інструмент тесту

Логін через інтерфейс у кожному тесті — найдорожчий спосіб отримати стан, який віддається одним запитом. Токен беруть один раз і підкладають у заголовки, а дані готують викликом API замість проходу майстра.

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

test.use({
  extraHTTPHeaders: {
    Authorization: `Bearer ${process.env.API_TOKEN}`,
    Accept: 'application/json',
  },
});

test('часткове оновлення не чіпає непередані поля', async ({ request }) => {
  const before = await (await request.get('/api/users/42')).json();

  // PATCH везе інструкцію змінити одне поле, а не нове подання ресурсу
  const res = await request.patch('/api/users/42', { data: { role: 'admin' } });
  expect(res.status()).toBe(200);

  const after = await (await request.get('/api/users/42')).json();
  expect(after.role).toBe('admin');
  expect(after.email, 'PATCH не мав чіпати email').toBe(before.email);
});

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

test('неповний PUT затирає непередані поля', async ({ request }) => {
  await request.put('/api/users/42', { data: { role: 'admin' } });

  const after = await (await request.get('/api/users/42')).json();
  // якщо контракт вимагає цілісне подання — email тут уже порожній
  expect(after.email, 'контракт: PUT замінює ресурс цілком').toBeFalsy();
});

Файл у формі передають обʼєктом, а не складеним руками тілом: бібліотека сама поставить роздільник, filename і тип частини.

test('завантаження звіту приймає PDF', async ({ request }) => {
  const res = await request.post('/api/upload', {
    multipart: {
      title: 'Some report name',
      file: {
        name: 'report.pdf',
        mimeType: 'application/pdf',
        buffer: Buffer.from('%PDF-1.4 ...'),
      },
    },
  });

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

А ось спроба, яка виглядає робочою й тихо нічого не робить.

// НЕ спрацює: Cookie у переліку forbidden request-header —
// підміну проігнорують, запит поїде з реальними кукі, тест зеленітиме дарма
await page.route('**/api/**', (route) =>
  route.continue({
    headers: { ...route.request().headers(), cookie: 'role=admin' },
  }),
);

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

• Токен у заголовку економить не хвилини, а стабільність. Кожен прохід логіну через інтерфейс додає тесту чужі точки відмови — рендер, анімації, CAPTCHA, — жодна з яких до предмета перевірки не має стосунку.
• Різницю PUT і PATCH перевіряють станом після запиту, а не кодом відповіді. 200 прийде в обох випадках; втрачений email видно лише наступним GET.
• Заборонені заголовки не сигналізують про помилку. Підміна Cookie, Host, Origin чи Referer мовчки не застосовується — тому кожен сценарій із підміною потребує асерту, який доводить, що нове значення справді доїхало.
• Тіло multipart руками не складають. Роздільник має бути унікальним і не траплятися всередині жодної частини; зламавши його, ви налагоджуватимете власний конверт замість застосунку.
• Секрет у тілі, а не в адресі. Той самий токен, переданий query-параметром, осяде в історії браузера, логах сервера й реферерах — і це вже не зручність тесту, а знахідка для security-репорту.

Будова повідомлення

• Можу назвати чотири частини по порядку, показати, що схема однакова для запиту й відповіді, і пояснити, чому порожній рядок — елемент синтаксису, а не форматування.
• Розумію, чому асертять число статусу, а не пояснювальну фразу поруч: клієнту рекомендовано на неї не спиратися, а в HTTP/3 місця під неї немає взагалі.

Семантика методів

• Можу перелічити три наскрізні властивості методу — безпечність, ідемпотентність, кешованість — і показати, що осі не збігаються: PUT ідемпотентний, але ні безпечний, ні кешований.
• Знаю точне означення безпечного методу («лише читання» з погляду клієнта), чому «без побічних ефектів» — спрощення, і навіщо цей поділ узагалі існує: заради краулерів і префетчу.
• Розумію, що протокол фіксує намір, а не гарантує поведінку, і тому видалення, повішене на GET, — дефект контракту, а не місцева особливість реалізації.
• Знаю різницю PUT vs PATCH за вмістом тіла (готове подання проти набору інструкцій), памʼятаю ризик затирання непереданих полів і те, що формат тіла PATCH одним стандартом не закріплений — дивлюсь контракт.
• Тримаю в голові пастку HEAD: тіла у відповіді немає нормативно, а Content-Length сервер має право не віддати, тож перевірка розміру без переконання, що поле прийшло, дає плаваюче падіння.

Ідемпотентність і ретраї

• Знаю означення через стан сервера, перелік ідемпотентних методів і неідемпотентну трійку POST, PATCH, CONNECT.
• Не плутаю стан сервера з відповіддю: 404 на повторний DELETE ідемпотентність не порушує, і тест має його очікувати.
• Розумію, чому однакове тіло не робить PATCH ідемпотентним, вмикаю ретрай за методом, а побачивши дублі — спершу дивлюсь налаштування повторів у самому HTTP-клієнті, і лише потім підозрюю продукт.

Заголовки

• Знаю різницю Content-Type vs Accept за напрямком: перший описує вміст, який їде зараз, другий — вигляд, у якому клієнт чекає майбутню відповідь.
• Памʼятаю нормативний код на непідтримуваний формат тіла — 415, — і називаю 400 на цьому місці відступом, який варто згадати в баг-репорті.
• Розумію ваги q в узгодженні вмісту: діапазон від нуля до одиниці, відсутність ваги дорівнює одиниці, q=0 — відмова, а не низький пріоритет.
• Знаю про forbidden request-header і головний симптом: підміна Cookie, Host, Origin чи Referer мовчки ігнорується, тест зеленіє даремно, а User-Agent підміняється саме тому, що в переліку його немає.
• Можу пояснити, чому Basic без TLS не захист (base64 — кодування, роздільником пари є перша двокрапка), і не плутаю 401 із WWW-Authenticate та 407 із Proxy-Authenticate: друга пара веде в мережеву конфігурацію стенда, а не в код застосунку.

Тіло, query і multipart

• Можу назвати запити з тілом (POST, PUT, PATCH) і відповіді без нього (204, відповідь на HEAD) — і перевіряю статус до того, як братися розбирати тіло.
• Обираю між query і тілом за трьома критеріями — структура, видимість, ліміт довжини, — памʼятаю порядок величин (близько 8 кБ на рядок запиту проти гігабайта на тіло за замовчуванням) і не пускаю секрети в адресу.
• Можу описати склад multipart/form-data: частини з власними заголовками, унікальний boundary, filename і тип у частині з файлом — і не складаю таке тіло руками.

Безстановість і версії протоколу

• Розділяю безстановий протокол і застосунок зі станом, знаю, чим стан приносять (кукі або токен), і памʼятаю, що «увійти один раз на всю сесію» на рівні протоколу не існує.
• Знаю, що HTTP/2 змінює подання, а не семантику: псевдозаголовки замість стартового рядка, ті самі методи й коди — тому контрактні тести переїзд не переписує.