Теоретичний вступ до вебсервісів

Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics.

Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.

У моноліті UI, business logic, persistence і integrations можуть постачатися як один application. У microservice architecture users, products і orders можуть жити в окремих services і мати власні data stores.

Дрібні services не гарантують простоти: зростають coupling, deployment overhead і складність пошуку failure. Тому test architecture має відображати фактичні service boundaries, а не ідеалізовану діаграму.

Запит від browser, mobile або IoT device може пройти DNS, load balancer/API gateway, потім один або кілька services. Java backend у прикладі будується на Spring/Spring Boot, читає database або публікує asynchronous event.

Kafka, RabbitMQ та інші brokers допомагають розв’язати producer і consumer у часі. Для тестів це означає, що request success не завжди доводить completed business outcome: потрібно перевіряти event publication, processing, retries і final state.

REST пояснюється як набір architectural constraints/recommendations, а HTTP — як application protocol для client–server communication. Ці терміни не є синонімами.

Ресурс представляє domain entity у контракті, URI ідентифікує його, а HTTP method виражає operation. Тест має перевіряти не лише response body, а й method semantics, headers, status і state transition.

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. Запит на конкретний nonexistent resource зазвичай очікує 404, а фільтр collection без matches — 200 і empty result.

Ця різниця має бути явною в test cases: один сценарій перевіряє відсутність адресованої entity, інший — валідний empty search result.