При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.
Почему?
1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.
2. Разные механизмы требуют разной логики работы и обработки ошибок.
3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.
📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT (JSON Web Token)
OAuth 2.0
Mutual TLS (по сертификатам)
📌 Как оформлять в требованиях?
Важно понимать, что при работе с задачей на интеграцию, аналитик пишет требования к интеграционным API методам для своей системы, в логике которых встроены вызовы внешних API.
Например, для интеграции с API платежной системы ВТБ в #TravelGA, аналитику надо описать требования на API-методы:
✅ Создать платеж
POST https://travelga.com/api/public/v1/orders/{orderId}payments
в алгоритме работы которого будет вызов API-метода ВТБ.
✅ Получить статус платежа - аналогично
👉 В постановках задач на оба эти метода не нужно дублировать описание процесса авторизации в ВТБ и обработку её ошибок.
Достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё. А при описании отдельных API-методов фокусироваться только на специфике их работы.
📌 Обработка ошибок авторизации
Важно предусмотреть и описать требования к обработке в процессе работы интеграции:
❌ 401 Unauthorized — неверные или отсутствующие учётные данные.
❌ 403 Forbidden — недостаточно прав для выполнения операции.
❌ 419 Token Expired — срок действия токена истёк, требуется рефреш или повторная авторизация.
❌ 429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).
📌 Логирование
Логируйте и мониторьте случаи отказа авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".
#ИнтеграцииGA #vtbAPI