apiman.io — api-шлюз для интеграционного обмена с открытым кодом
Сначала о расскажу о проблеме. Нашей компании понадобился внешний шлюз для перенаправления API-запросов от партнеров к различным приложениям внутри компании.
Запросы нужно передавать для разных задач. Одна из них — интеграция внешних складских систем (WMS).
Основные требования к шлюзу:
Шлюз должен позволять настроить доступы к API компании для различных партнеров. Партнерам может быть доступен разный набор API.
Шлюз должен опознавать конкретного партнера и передавать его код (или наименование) дальше приложению внутри компании, обрабатывающему запрос. Например, код склада, выполняющего отгрузку.
Шлюз должен предоставлять хотя бы минимальную статистику обработанных запросов.
Продукт apiman.io был выбран по причине того, что это opensource, не имеющий каких-либо ограничений на использование.
Скажу сразу, что хотя продукт и заработал, но ощущения от него остались двоякие, поэтому было бы очень интересно узнать мнение и опыт других участников хабра, если такой опыт у кого-то есть.
С развертыванием пришлось повозиться. Потребовалось настроить Keycloak и Apiman на совместную работу (документация описывает процесс настройки не совсем понятно). Keycloak в нашем случае нужен только для доступа админа и взаимодействия компонентов самого Apiman, т.к. внешние клиенты авторизуются с использованием ключа в URL.
Сам продукт, тем не менее, по замыслу разработчиков, предполагается как система для взаимодействия нескольких ролей: админ, менеджер организации, разработчик api, разработчик на стороне партнера. Интегрировать Keycloak ради доступа админа выглядит как перебор, но без этого никак.
Опишу структуру и возможности этого продукта. Надо сказать, что структура сложная и имеет множество абстрактных объектов, назначение которых угадывается неоднозначно. Пришлось переделывать конфигурацию пару раз, прежде чем пришло понимание, что есть что в нашем случае.
1) Организации — можно создать несколько организаций. В нашем случае пока одна.
2) Планы — некий набор настроек, который может использоваться внутри API. В нашем случае соответствует списку внутренних систем и содержит логин для внутренней авторизации.
3) API — у каждой организации свой набор API. API имеет имя и внешний адрес. В настойках указан внутренний адрес, на который нужно маршрутизировать запрос. Для каждого API нужно указать план (т.е. в нашем случае внутреннюю систему).
API имеет версии, которые указаны как часть адреса. Очень неудобно, что нельзя редактировать старые версии API, а только создавать новые версии. Для редактирования параметров без изменения версии приходится удалять API и создавать его заново. (зачем так сделали — загадка).
Внешний адрес API выглядит примерно так: https://ваш_хост/apiman-gateway/организация/название_API/1.0? apikey=код_доступа_клиентского_приложения
4) Клиентские приложения — партнер, который использует API. Набор доступных API прописывается в виде контрактов (т.е. по сути это права доступа). Для клиентского приложения прописываем правило добавлять к заголовку код (или наименование) партнера, чтобы внутреннее приложение могло его идентифицировать как определенного партнера.
5) Шлюзы — в теории Apiman поддерживает работу через несколько шлюзов. Мы используем один шлюз.
6) Роли — позволяет сделать отдельные роли для разработчиков API и для разработчиков на стороне партнера. Не знаю, возможно ли использовать на практике, т.к. такой вариант настройки не требовался. В целом в продукт входит портал для партнеров, который нам не удалось настроить из за ошибок. Похоже портал еще не доделан разработчиками apiman (хотя может я и не прав).
7) Метрики — можно просмотреть график с количеством успешных и неуспешных запросов к каждому API в разрезе клиентских приложений.
8) Политики — некие дополнительные правила, которые можно прикреплять к плану или непосредственно к API. Например, можно прописать «Header Rewrite Policy», чтобы добавить нужный заголовок с кодом партнера. Также есть «Log Headers Policy», которая позволяет кидать заголовки запросов и ответов в лог.
Привожу скрин общего меню приложения и пунктов, которые доступны для конкретного API:
Меню администратора
Вот так выглядит статистика. (В этом примере были сбои доступа к приложению по причине сетевых проблем, которые можно видеть на графике):
По результатам нескольких месяцев использования, можно сказать, что Apiman работает стабильно.
Также видно, что продукт развивают и, возможно, в ближайшем будущем его доведут до ума в части документации, а также доделают Developer Portal.
