Описание проекта
Мы отдаём несколько внутренних API внешним клиентам и партнёрам, и сейчас каждая интеграция обращается напрямую к нашим сервисам. Управлять этим стало невозможно: не видно, кто и какие методы вызывает, нельзя отключить недобросовестного потребителя, а один партнёр с плотным циклом запросов способен просадить платформу для остальных. Требуется поставить перед этими сервисами API-шлюз, чтобы каждый запрос проходил через единую контролируемую точку входа до внутренних систем.
Шлюз должен отвечать за аутентификацию и выдавать API-ключи на каждого партнёра, с возможностью отозвать или перевыпустить ключ без правок в коде. Поверх этого нужны rate limiting и месячные квоты на ключ, маршрутизация запросов на нужный upstream-сервис и кеширование ответов для тяжёлых на чтение методов. Не менее важна аналитика: по каждому партнёру объём вызовов, доля ошибок, задержки и расход квоты — для планирования мощностей и тарификации.
Готовы рассмотреть продукт-шлюз или аккуратное собственное решение, но оно должно лечь на наш стек. Опишите подход, как перенесёте интеграции за шлюз без простоя и как будут настраиваться ключи, лимиты и маршруты. Опыт с боевыми API-шлюзами обязателен.
Шлюз должен отвечать за аутентификацию и выдавать API-ключи на каждого партнёра, с возможностью отозвать или перевыпустить ключ без правок в коде. Поверх этого нужны rate limiting и месячные квоты на ключ, маршрутизация запросов на нужный upstream-сервис и кеширование ответов для тяжёлых на чтение методов. Не менее важна аналитика: по каждому партнёру объём вызовов, доля ошибок, задержки и расход квоты — для планирования мощностей и тарификации.
Готовы рассмотреть продукт-шлюз или аккуратное собственное решение, но оно должно лечь на наш стек. Опишите подход, как перенесёте интеграции за шлюз без простоя и как будут настраиваться ключи, лимиты и маршруты. Опыт с боевыми API-шлюзами обязателен.
Веб программирование Наличные, Банковский перевод
