Комментарии 3
Любопытное решение. Спасибо, что поделились.
Насчет сложности с менеджментом и обслуживанием, возможно, есть смысл сделать ваш API-реестр, включая структуры данных для обмена через API и API Gateway Management более Data-Driven.
То есть:
- завести все эти компоненты в реляционную базу данных.
- Создать единую структуру данных для обмена банковской информации (Banking Schema),
- Из Banking Schema вытаскивать необходимые entities with properties, как Sub-Schema из вашей гигантской Banking Schema.
- Все ваши API-сервисы в API-реестре хранить в базе данных, чтобы каждый API-сервис опирался на Associated Sub-Schemes.
- на основании request/response Sub-Schemes генерить OpenAPI.
- Все API Gateway также хранить в базе данных и назначать каждому API Gateway те API сервисы, которые он должен обрабатывать.
И так далее, с похожим Data-Driven подходом.
А далее на все это реалиционное чудо навесить пользовательский интерфейс для управления и скрипты для автоматической пропагейшн API Services on API Gateways.
Мне кажется, с точки зрения архитектуры, такой подход будет более масштабируемым и управляемым.
Что скажете?
Спасибо за вопрос. Хороший комментарий, но у нас такое пока что не реализуемо в масштабах банка.
Слишком много изолированных друг от друга команд со специфическими задачами. Такой сценарий можно реализовать в рамках смежных команд, где можно переиспользовать методы и данные.
Но как сверхзадача для последующего развития API Gateway очень даже интересная идея!
В Штатах есть организация MISMO и они последние 25 лет как раз занимаются стандартизацией структуры данных для банковского кредитования США и определением структур данных для различных банковских сервисов.
Начинали с малого, но сейчас система похожа на вышеописанную.
Если что, пишите, буду рад поделиться опытом.
Система управления проектированием API банка: от создания интерфейса до импорта спецификации