Перейти к основному содержимому

Спецификация + REST API

Пример реальной спецификации (ключевые выдержки, полная версия — 34 страницы). Проект: разработка подписки «Газпром Бонус» — интеграция Системы Партнера (СП) с API программы лояльности Газпромбанка (ГПБ).

User Story

Как пользователь продуктов Экосистемы Газпром, я хочу оплачивать покупки бонусами, начисленными за оплату картой ГПБ, чтобы экономить.

Как владелец продукта групповой лояльности ГПБ, я хочу, чтобы пользователь оплачивал покупки в продуктах экосистемы бонусами, чтобы усилить его вовлечённость в продукты Банка и Экосистемы.

Контекст

В Банке реализован механизм начисления баллов по механике кэшбэка. Для доставки ценности нужен механизм использования баллов у партнёров. Участники MVP: Газпромнефть, Gorod Pay, Газпромбанк Мобайл, Шоколадница.

В данной схеме мы выступаем в роли прокси между сервисом Партнёра и Банком.

Use case

Отображение баланса баллов

PlantUML диаграмма

Списание баллов

PlantUML диаграмма

Проверка согласия Пользователя

PlantUML диаграмма

Методы партнерского API

GET /v1/group-loyalty/balance

Назначение: предоставление партнёру данных по балансу баллов клиента Банка.

Заголовки:

ПараметрТипОбязательностьОписание
X-Global-Transaction-IdguidдаИдентификатор запроса

Query-параметры:

ПараметрТипОбязательностьОписание
idguidдаСквозной идентификатор операции в системе партнёра (для логов)
phone_numberstringдаИдентификатор клиента (номер телефона)

Ответ:

ПараметрТипОписание
phone_numberstringИдентификатор клиента
balanceintБаланс баллов клиента
error_codeintКод отказа при HTTP 200: 1 — не найден клиент, 2 — нет согласия

Пример ответа:

{
"phone_number": "79006578435",
"balance": 100
}

POST /v1/group-loyalty/bonus/charge_off

Назначение: списание / отмена списания баллов клиента.

Body-параметры:

ПараметрТипОбязательностьОписание
idguidдаИдентификатор транзакции (при отмене — id запроса списания)
phone_numberstringдаИдентификатор клиента
partner_idintдаИдентификатор партнёра в системе Банка
amountintдаСумма баллов
typeintда1 — списание, 2 — отмена

Пример запроса:

{
"id": "6F9619FF-8B86-D011-B42D-00CF4FC964FF",
"phone_number": "79001234567",
"partner_id": 12,
"amount": 1000,
"type": 1
}

Ответ: error_code при HTTP 200: 1 — не найден клиент; 2 — нет согласия; 3 — недостаточный баланс или не найдена транзакция; 4 — запрос уже был выполнен успешно.

GET /v1/group-loyalty/consent

Назначение: проверка наличия согласия пользователя.

Ответ:

ПараметрТипОписание
phone_numberstringИдентификатор клиента
consentbooleanПризнак наличия согласия
date_on / date_offdatetimeДаты предоставления / отзыва согласия (зарезервировано на будущее)
error_codeint1 — не найден клиент

Обработка ошибок: маппинг ответов ГПБ → Шлюз СП

Ключевая логика — подмена кода ответа: 401 от GPB-API при трансляции партнёру преобразуется в 421.

Причина ошибкиОтвет ГПБОтвет Шлюза СП
1Пользователь не найден200 (error_code=1)200 (error_code=1)
2Слишком много запросов429429
3Ошибка сервера500 / 504500
4Некорректный запрос400400
5Ошибка авторизации401421
6Сервис ГПБ недоступенtimeout error500
7Нет согласия200 (error_code=2)200 (error_code=2)
8Недостаточно баллов / не найдена транзакция200 (error_code=3)200 (error_code=3)
9Запрос уже был выполнен успешно200 (error_code=4)200 (error_code=4)

Логирование, метрики, роли

  • Для логов и метрик (http_client_request_total, http_client_request_latency_bucket) заведены имена методов: partner_get_bonuses, partner_charge_off_bonuses, partner_consent.
  • Логирование запросов/ответов к Шлюзу СП и ГПБ; чувствительные данные не логируются в открытом виде.
  • Добавлена роль тенанта b2b-user-loyalty-system (read/write) для методов партнёрского API; фронт поддерживает отображение новой роли.

Нефункциональные требования

  • Kredы хранятся в секретах, а не в переменных окружения.
  • SLA 24/7: 99.9%.
  • Пиковая нагрузка MVP: 996 операций в час (0.28 оп/сек).
  • Гарантированное время ответа от ГПБ API: 60 сек.
  • Масштабируемость: добавление партнёра с 20 млн клиентов.
  • Отдельный домен и IP → отдельный балансировщик → отдельный Kubernetes.

Критерии приёмки

  1. Описанные методы API реализованы.
  2. Осуществляется подмена кода ответа (401 → 421).
  3. Новая роль тенанта отображается на фронте.
  4. Доступ партнёров работает согласно ролевой модели.
  5. Нефункциональные требования выполнены.