Концепции

Основные понятия

Шлюз API

Интерфейс взаимодействия, который находится перед API группы микросервисов. Облегчает отправку запросов и доставку данных сервисов.

Назначения шлюза:

• Выступать в качестве единой точки входа и стандартизированного процесса взаимодействия между различными сервисами организации в рамках одного сценария использования.

• Выполнять функцию прослойки между API и базовой инфраструктурой.

• Поддерживать и управлять использование API, включая авторизацию, ограничение числа запросов в единицу времени и другие службы.

Шлюз API является контейнером для правил. Все правила, размещенные в шлюзе, реализуют перенаправление запросов, отправленных на адрес шлюза API, к группе микросервисов. Адрес шлюза генерируется автоматически при создании шлюза и доступен в разделе Информация.

Правило

Набор свойств, согласно которым обрабатываются запросы клиента к шлюзу API, в котором это правило создано, по заданным правилам соответствия HTTP-метода и URI запроса. Определяет сценарий обработки запросов, поступивших на выбранные URI шлюза API, а совокупность правил определяет всю логику пользовательского взаимодействия со шлюзом API.

К правилу можно привязать плагины, которые обогащают логику обработки запросов.

URI

URI бэкенда и URI для proxy указываются при создании правила.

URI бэкенда определяет конечную точку пользовательского бэкенда, к которой будут отправляться запросы через шлюз. Пример:

• Адрес хоста бэкенда: https://example.com

• URI бэкенда: /service

Запросы будут отправляться на https://example.com/service.

Если при создании правила вы выбрали подключение, в настройках которого в качестве протокола указан GRPC/GRPCS, то в поле URI бэкенда укажите путь в следующем формате: /package.service/rpc, где:

• package — название пакета в proto-файле;

• service — название сервиса в proto-файле;

• rpc — метод в proto-файле.

Примечание

Подробнее о настройке протокола GRPC и синтаксисе proto-файла — на официальном сайте разработчика.

URI для proxy используется в адресе шлюза при проксировании запросов. Пример:

• Адрес шлюза: https://9cd8da9051.apigw.cloud.ru

• URI для proxy: /service1

Для отправки запросов к бэкенду через шлюз будет использоваться адрес https://9cd8da9051.apigw.cloud.ru/service1.

В значении URI для proxy и URI бэкенда можно использовать wildcard-символ (*) для обозначения произвольной части пути. Пример для URI для proxy:

• при добавлении URI /foo* (для обращения по HTTP) правилом будут обработаны запросы на /foo/, /foo/a, /foo/b и так далее;

• при добавлении URI /package.service/* (для обращения по GRPC) правилом будут обработаны запросы на /package.service/SayHello, /package.service/PostArticle и так далее.

Плагин

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

Плагины могут быть привязаны только к конкретному правилу и модифицируют выполнение только тех запросов, которые соответствуют настройкам правила. К каждому правилу могут быть привязаны все доступные плагины, но только по одному каждого типа.

См.также

Настройки плагинов для правил

Пример взаимосвязи объектов