API testing: course

API Gateway (шлюз)

 

Що таке API-шлюз (API Gateway)?

API Gateway – це посередник між клієнтом (користувачем або сервісом) і бекенд-сервісами. Він приймає запити, перевіряє їх, маршрутизує до потрібного сервісу, обробляє відповіді та відправляє їх назад клієнту.

Що це?

  1. Єдина точка входу – клієнти не взаємодіють напряму з мікросервісами.
  2. Безпека – перевірка аутентифікації та авторизації. Тут важливо! доволі часто API Gateway виконує саме функцію аутентифікації та авторизації а не на самому дочірньому сервісі
  3. Кешування – зменшення навантаження на сервери.
  4. Балансування навантаження – рівномірний розподіл трафіку.
  5. Перетворення запитів – API Gateway може конвертувати формат даних. наприклад: API Gateway може конвертувати формат даних між gRPC(тут тільки бінарні дані юзаються) та REST (або іншими протоколами), що робить можливим використання gRPC-сервісів клієнтами, які підтримують тільки HTTP/JSON. 

 

Як це працює з gRPC?

API Gateway може виступати як проксі-сервер, який:

  1. Приймає RESTful HTTP-запити (JSON).
  2. Перетворює їх у gRPC-запити.
  3. Відправляє їх до gRPC-сервісу.
  4. Отримує відповідь у gRPC.
  5. Перетворює відповідь у JSON і надсилає клієнту.

https://www.wallarm.com/what/the-concept-of-an-api-gateway

Як це працює?

  1. Клієнт відправляє запит до API Gateway.
  2. API Gateway перевіряє запит (аутентифікація, кеш, політики доступу).
  3. API Gateway пересилає запит до відповідного бекенд-сервісу.
  4. Отримує відповідь, обробляє її та повертає клієнту.

Приклад роботи API Gateway

Уявімо, що у нас є інтернет-магазин, і ми хочемо отримати дані про користувачів та їхні замовлення. У нас є два мікросервіси:

  • User Service – зберігає інформацію про користувачів.
  • Order Service – зберігає інформацію про замовлення.

Клієнту потрібно отримати дані про користувача разом із його замовленнями.

 

Без API Gateway:

Клієнт робить два окремі запити:

GET https://api.shop.com/users/123
GET https://api.shop.com/orders?userId=123

Відповідь збирається на клієнті.

З API Gateway:

Клієнт робить один запит:

GET https://api.shop.com/user-orders/123

API Gateway виконує два запити до мікросервісів, об'єднує їх і повертає єдину відповідь.

Приклад API Gateway на AWS API Gateway

1. Запит від клієнта

GET https://api.example.com/user-orders/123

Відповідь:

 

GET https://users-service/api/users/123

2. API Gateway виконує два запити:

{
  "id": "123",
  "name": "Bohdan"
}

Відповідь:

 

GET https://orders-service/api/orders?userId=123
{
  "orders": [
    { "id": "1", "total": 100 },
    { "id": "2", "total": 250 }
  ]
}

3. Після цього API Gateway об'єднує ці дві відповіді та відправляє клієнту єдиний JSON:

 

Відповідь:

 

{
  "user": {
    "id": "123",
    "name": "Bohdan"
  },
  "orders": [
    { "id": "1", "total": 100 },
    { "id": "2", "total": 250 }
  ]
}

АБО!
Клієнт звертається через API Gateway, але об'єднання робить сам. У цьому випадку API Gateway лише проксує запити до відповідних сервісів, але не об'єднує їх.

📌 Що тут робить API Gateway?

- Виконує автентифікацію (JWT, API Key).
- Контролює Rate Limiting (обмеження запитів).
- Виступає єдиною точкою входу (https://api.example.com замість декількох URL).

Тестування

Тестування API Gateway включає кілька рівнів: функціональне тестування, навантажувальне тестування, безпекове тестування, тестування логування та моніторингу.

1. Функціональне тестування

2. Тестування безпеки

3. Навантажувальне 

4. Моніторинг та логування

тут все те саме що в API сервісів нижче проте API Gateway та мікросервіси виконують різні ролі, тому їхнє тестування окремо дозволяє виявити проблеми на різних рівнях.

API Gateway не відповідає за бізнес-логіку - він лише маршрутизує запити, застосовує кешування, обробляє помилки, проводить аутентифікацію. Логіка та обробка даних відбувається у сервісах.

Локалізація помилок: якщо тестувати тільки API Gateway, важко зрозуміти, чи проблема у маршрутизації чи в бекенді. Тут досліджуємо! і записуємо хто за що відповідає

тут дуже прям класно проводити інтеграційне тестування (API Gateway + мікросервіси)

Після тестування окремо, треба перевірити спільну роботу API Gateway та сервісів.

👉 Чи правильно API Gateway маршрутизує запити?
👉 Чи не змінюється структура даних при проксуванні?
👉 Чи правильно працює аутентифікація?

Тому

 

🤌 Мікросервіси тестуємо окремо: їхню логіку, роботу з БД, API-контракти
🤌 API Gateway тестуємо окремо: маршрутизацію, кешування, безпеку
🤌 Разом тестуємо інтеграцію: чи правильно API Gateway передає та об'єднує дані