Компания держит сервис обработки данных, и его служебный API за пару лет вырос в главную ценность бизнеса — внешние команды уже не первый месяц просят подключить их напрямую. Плодить индивидуальные интеграции под каждого клиента мы больше не хотим, поэтому решили оформить API как отдельный коммерческий продукт с прозрачной продажей доступа. Задача — надстроить над открытым сегодня внутренним эндпоинтом управляемый самообслуживаемый слой: человек регистрируется, получает ключ доступа, подбирает подходящий план, за несколько минут делает первые запросы и в любой момент понимает, за что именно списываются средства. Саму логику обработки трогать не нужно, требуется только грамотная обвязка доступа и тарификации вокруг неё.
Технически это шлюз или прослойка, которая проверяет подлинность каждого обращения по ключу, держит квоты и ограничение частоты согласно выбранному плану и складывает каждый вызов в счётчик для последующей оплаты. Подсчёт обязан быть безошибочным и устойчивым к повторам запроса, иначе расхождения в счётчиках приведут к спорам по счетам. Оплата строится по фактическому потреблению и разбита на уровни: бесплатный ознакомительный, несколько коммерческих и отдельный корпоративный с договорными лимитами; нужны учёт перерасхода и помесячное выставление счетов через наш платёжный шлюз. Отдельно требуется кабинет разработчика, где клиент сам заводит и отзывает ключи, наблюдает расход онлайн, открывает документацию и переключает тариф без переписки с нами. И для себя мы хотим служебную статистику: какие методы вызывают чаще всего, сколько приносит каждый клиент, где заметны попытки злоупотреблений.
До начала кодирования жду от исполнителя схему архитектуры с ясным ответом, как удержать корректность подсчёта при высокой нагрузке и как безопасно хранить и обновлять ключи. Принципиально, чтобы шлюз, расчётный модуль и кабинет были разделены и могли развиваться по отдельности.
— Генерация ключей доступа, разграничение прав и безопасное обновление
— Подсчёт вызовов: без ошибок, устойчивый к повторам, пригодный для проверки
— Ограничение частоты и квоты под каждый тарифный план
— Оплата по потреблению с учётом перерасхода и выставлением счетов
— Самообслуживаемый кабинет разработчика с показом расхода онлайн
— Служебная статистика: популярные методы, доход по клиентам, поиск злоупотреблений
Технически это шлюз или прослойка, которая проверяет подлинность каждого обращения по ключу, держит квоты и ограничение частоты согласно выбранному плану и складывает каждый вызов в счётчик для последующей оплаты. Подсчёт обязан быть безошибочным и устойчивым к повторам запроса, иначе расхождения в счётчиках приведут к спорам по счетам. Оплата строится по фактическому потреблению и разбита на уровни: бесплатный ознакомительный, несколько коммерческих и отдельный корпоративный с договорными лимитами; нужны учёт перерасхода и помесячное выставление счетов через наш платёжный шлюз. Отдельно требуется кабинет разработчика, где клиент сам заводит и отзывает ключи, наблюдает расход онлайн, открывает документацию и переключает тариф без переписки с нами. И для себя мы хотим служебную статистику: какие методы вызывают чаще всего, сколько приносит каждый клиент, где заметны попытки злоупотреблений.
До начала кодирования жду от исполнителя схему архитектуры с ясным ответом, как удержать корректность подсчёта при высокой нагрузке и как безопасно хранить и обновлять ключи. Принципиально, чтобы шлюз, расчётный модуль и кабинет были разделены и могли развиваться по отдельности.
— Генерация ключей доступа, разграничение прав и безопасное обновление
— Подсчёт вызовов: без ошибок, устойчивый к повторам, пригодный для проверки
— Ограничение частоты и квоты под каждый тарифный план
— Оплата по потреблению с учётом перерасхода и выставлением счетов
— Самообслуживаемый кабинет разработчика с показом расхода онлайн
— Служебная статистика: популярные методы, доход по клиентам, поиск злоупотреблений
