REST API
Сначала контракт API, затем автоматизация
Наличие REST API не означает готовый универсальный источник: назначение, методы и направление обмена подтверждаются по документации конкретной системы.
Определить направление и объект
Нужно различить API самого Glarus BI для документированных операций и внешний API, из которого планируется получать данные. Для каждого сценария записываются сущность, методы, версия, среда и владелец контракта. Произвольный JSON не объявляется автоматически поддержанным источником.
- Endpoint и версия контракта
- Направление чтения или управления
- Авторизация и область прав
- Контрольный объект и ожидаемый результат
Проверить протокол получения
Изучаются пагинация, фильтры по дате изменения, лимиты, повтор запросов, коды ошибок и срок хранения истории. Полная перезагрузка и инкрементальный режим дают разные риски. Rate limit и временная недоступность должны приводить к наблюдаемой ошибке, а не к неполному дашборду.
Зафиксировать схему и секреты
Поля, типы, вложенные объекты и идентификаторы описываются как версионируемый контракт. Токены и ключи хранятся вне сайта и репозитория, получают минимальные права и процедуру ротации. Персональные данные включаются только в необходимом и согласованном объёме.
Принять данные, а не только HTTP 200
Технический ответ сервера не подтверждает полноту аналитики. На известном периоде сверяются число объектов, уникальные ключи, удалённые записи, часовой пояс и контрольный показатель. После этого фиксируются расписание, мониторинг и действие при изменении версии API.
Частые вопросы
Можно подключить любой REST API?
Нет общего обещания: контракт, авторизация, лимиты и способ загрузки оцениваются отдельно.
Где хранить токен?
Во внешнем защищённом хранилище или настройке контура с минимальными правами и ротацией.
Достаточно проверить код 200?
Нет. Нужна сверка полноты, ключей, периода и бизнес-показателя.