Шаблон “API-шлю甶

Подход, при котором клиенты выполняют множество запросов к сервисам для отображения информации, имеет определенные недостатки. Поэтому лучше сделать так, чтобы клиент делал один запрос к API-шлюзу, сервису, который служит единой точкой входа для запросов к приложению извне.
Исходя из этого шлюзу разумно делегировать выполнение следующих функций.

Маршрутизация запросов¶

Некоторые API-вызовы реализуются путем направления запросов подходящим сервисам. В этом случае шлюз выступает в качестве reverse proxy, обращаясь, например, к реестру сервисов.

Объединение API¶

Некоторые вызовы разумно реализовывать, используя объединение API на шлюзе.

Преобразование протоколов¶

Внешние клиенты чаще всего обращаются к приложению на основе RESTful API, однако внутри сервисы могут использовать самые различные протоколы. Шлюз преобразовывает внешние REST запросы к внутренним.

API-шлюз предоставляет каждому клиенту отдельный API¶

Так как у разных клиентов разные требования к API, не очень рационально формировать универсальный API. Лучше сделать так, чтобы шлюз выделял каждому клиенту отдельный API - например, API для мобильного приложения (и даже разные версии для iPhone и Android, если это необходимо), а также отдельный API для сторонних разработчиков. См. также шаблон BFF.

Реализация граничных функций¶

Граничные функции — операции обработки запросов на границе приложения. Например,

• аутентификация — проверка подлинности клиента, делающего запрос
• авторизация — проверка того, что клиенту позволено выполнять операцию
• ограничение частоты запросов — контроль над тем, сколько запросов в секунду могут выполнять определенный клиент и/или все клиенты вместе
• кэширование — кэширование ответов для снижения количества запросов
• сбор показателей — сбор показателей использования API для анализа, связанного с биллингом
• ведение журнала запросов

В приложении есть три участка, где можно реализовать граничные функции. Прежде всего это внутренние сервисы. Подходит для кэширования, сбора показателей, возможно, авторизации. Однако аутентификацию лучше проводить до сервисов.
Второй участок — специализированный граничный сервис (до API-шлюза). Преимущества — разделение ответственности, единая точка реализации аутентификации (и других функций). Недостаток — повышение сложности и сетевой латентности.
Третий вариант — реализация граничных функций в API-шлюзе.

Архитектура API-шлюза¶

Модель владения в API-шлюзе¶

Трудности проектирования API-шлюза¶

Комментарии

Комментарии