Клієнт-сервер і REST

Клієнт і сервер: хто за що відповідає

Клієнт просить, сервер вирішує й відповідає. Клієнт — це браузер, мобільний застосунок або Postman. Сервер тримає бізнес-логіку і доступ до бази даних; клієнт ніколи не ходить у базу напряму.

Шлях одного запиту, коли користувач натиснув «Переказати» в банківському застосунку:

1. DNS перетворює домен у IP-адресу сервера.
2. Встановлюється TCP-з'єднання і TLS-шифрування (HTTPS).
3. Клієнт надсилає HTTP-запит: POST /api/transfers з токеном і JSON-тілом.
4. Load balancer або API Gateway передає запит одному з інстансів сервера.
5. Сервер перевіряє авторизацію, валідує дані, виконує бізнес-логіку: чи вистачає коштів, чи не перевищені ліміти.
6. Сервер читає й пише в базу в межах транзакції.
7. Сервер повертає відповідь: статус 201, заголовки, JSON з id переказу.
8. Клієнт показує результат користувачеві.

Для тестувальника важливо, що на кожному кроці може бути своя проблема: DNS чи сертифікат на стенді, балансувальник, що веде на старий інстанс, бізнес-логіка або транзакція, яка записала половину даних. Коли я розумію цей шлях, мені легше локалізувати баг і правильно описати його в репорті.

Три думки, які питають на співбесіді

HTTP — stateless. Кожен запит незалежний, сервер не пам'ятає попередній. Тому токен або cookie передають у кожному запиті. Для тестів це означає, що будь-який запит можна відтворити окремо, якщо в нього є всі потрібні заголовки.

Валідація на клієнті — зручність, на сервері — безпека. Форму в UI можна обійти, відправивши запит напряму з Postman або curl. Якщо сервер довіряє лише фронтенду, можна передати від'ємну суму чи чужий id. Саме тому API тестують окремо від UI, а не лише через інтерфейс.

Де шукати баг. Логіка проста:

• Неправильний запит у DevTools — баг фронтенду.
• Правильний запит, але хибна відповідь — баг бекенду.
• Правильна відповідь, але хибне відображення — знову фронтенд.

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

REST і альтернативи

REST — стиль побудови API, де дані — це ресурси за URL (/users/42), а дії над ними задають HTTP-методами: GET читає, POST створює, PUT і PATCH змінюють, DELETE видаляє. REST stateless, дані зазвичай передаються в JSON, а результат описується статус-кодом.

Альтернативи, які варто знати:

• GraphQL — один ендпоінт, клієнт сам описує, які поля йому потрібні.
• SOAP — XML і суворий контракт (WSDL), часто трапляється в старих банківських системах.
• WebSocket — постійне двостороннє з'єднання, наприклад для котирувань чи чату в реальному часі.

Для QA вибір стилю змінює підхід до тестування. У REST я перевіряю методи, статус-коди й ресурси. У GraphQL статус часто 200 навіть при помилці, і перевіряти треба масив errors у тілі. У SOAP важлива відповідність XML-схемі, а у WebSocket — порядок і доставка повідомлень.