HTTP status code
Тризначний code у межах 100–599, який повідомляє result HTTP request; 600 і вище не є valid HTTP status codes.
Вступ до API-автоматизації →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
GraphQL-over-HTTP не обмежується POST і status 200
Current GraphQL-over-HTTP draft requires POST support, permits GET for query operations, forbids GET for mutations and defines non-200 status handling. Тому transport contract треба тестувати за media type і operation, а не очікувати 200 для кожної відповіді.
Точну транспортну специфікацію відео не називає; перевірено проти current draft 2026-07-31.
Вступ до API-автоматизації →RFC 9110 §15: Status Codes
Нормативні semantics і valid range HTTP status codes.
Вступ до API-автоматизації → Першоджерело ↗HTTP success semantics
RFC 9110 визначає 200 OK як успішне виконання request. Для POST content описує status або результат дії. 202 Accepted означає, що request прийнято, але обробку ще не завершено.
RFC 9110: HTTP Semantics
Уточнює значення 200 OK, 202 Accepted і response content для POST.
REST як architectural style і HTTP protocol
REST пояснюється як набір architectural constraints/recommendations, а HTTP — як application protocol для client–server communication. Ці терміни не є синонімами. Ресурс представляє domain entity у контракті, URI ідентифікує його, а HTTP method виражає operation. Тест має перевіряти не лише response body, а й method semantics, headers, status і state transition.
REST, status codes і централізовані errors
Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.
HTTP methods і status codes як частина contract
`GET`, `POST`, `PUT`, `DELETE` мають різні очікувані effects. `200 OK`, `201 Created`, `202 Accepted`, `204 No Content`, client errors `4xx` і server errors `5xx` не слід згортати в одне «працює/не працює». Особлива увага приділяється `PUT`, де behavior для nonexistent resource залежить від contract. Автотест має кодувати домовленість конкретного API, а не універсально вважати один code правильним для всіх APIs.
Direct lookup і collection filtering
Відео завершується розрізненням direct lookup і collection filtering. Запит на конкретний nonexistent resource зазвичай очікує `404`, а фільтр collection без matches — `200` і empty result. Ця різниця має бути явною в test cases: один сценарій перевіряє відсутність адресованої entity, інший — валідний empty search result.
WebDriver і двостороння модель Playwright
Selenium виконує команди через WebDriver: тест звертається до драйвера HTTP-запитами, а драйвер керує браузером. Перевірки стану та explicit waits багаторазово опитують браузер, тому на віддаленому запуску через BrowserStack або іншу інфраструктуру network latency відчутно сповільнює тести й змушує змінювати polling interval. Playwright підтримує постійний двосторонній зв'язок із браузером і отримує результат виконаної команди через WebSocket. У відео це подається як причина меншої кількості мережевих затримок, кращої поведінки на remote execution і можливості працювати з Chromium, Firefox та WebKit через спільний API.
Вебсервіси, SOAP і RESTful
Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics. Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.
Consumer, producer і REST resources
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
Моноліт, модульний моноліт і мікросервіси
У моноліті business logic, email, SMS, persistence та integrations розгортаються як один application. Це не є автоматично погано: добре структурований моноліт простіший у розробці і не платить network latency за кожен внутрішній виклик. Модульний моноліт розділяє functionality всередині одного deployment і може зберігати окремі data boundaries. Мікросервісна архітектура виносить ці частини у незалежні services, але додає HTTP, serialization, handshakes, deployment і distributed failure modes.
`RequestSpecification`, authorization і content negotiation
`RequestSpecification` зберігає спільні налаштування request: `baseUri`, `basePath`, logging та інші параметри. Окремі specifications можуть описувати різні domains або request types, наприклад multipart. У тесті синтаксичні `when` і `then` можна опусти, якщо після HTTP method одразу обробляється `Response`. Token передається в authorization header. У RestAssured є спеціалізовані auth methods, але в прикладі header задається явно. `Content-Type` описує формат request body, `Accept` — бажаний формат response. Неправильний або відсутній header може дати `4xx`, тому потрібний набір перевіряється експериментально.
REST і GraphQL уже дають словник для API automation
У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.