HTTP API
Для получения данных и управления заявками по протоколу HTTP в торговой системе АЛОР Брокер предусмотрен интерфейс HTTP API.
Данный канал связи обеспечивает доступ к ресурсам системы в режиме «запрос — ответ» и предназначен для выполнения дискретных операций.
Особенности интерфейса
В основе HTTP API лежит модель передачи сообщений без сохранения состояния сессии. Каждое обращение клиента обрабатывается как независимая транзакция, что требует повторной передачи контекста или авторизационных данных в каждом запросе.
Такая модель взаимодействия имеет свои преимущества и недостатки при практическом использовании интерфейса.
| Преимущество | Недостаток |
|---|---|
| Изоляция запросов исключает потерю множества активных подписок при однократном разрыве соединения | Необходимость установки нового соединения для каждой операции увеличивает нагрузку на сетевую инфраструктуру |
| Возможность передачи значительных объёмов данных (например, исторических записей) единым массивом | Приём сообщений объёмом более 30 Мбайт создаёт высокую вычислительную нагрузку на клиентское ПО, а их передача — на серверную инфраструктуру |
| Упрощённая интеграция и автоматизация за счет отсутствия необходимости контроля жизненного цикла сессии | Ограничение темпа обновления данных скоростью опроса (polling) со стороны клиента |
| Использование стандартизированных кодов состояния HTTP для обработки ошибок и статусов запросов | Передача полных заголовков (headers) при каждом обращении увеличивает объём служебного трафика |
| Стабильная работа через стандартные сетевые шлюзы и брандмауэры без специфической настройки портов | Отсутствие инициативных уведомлений со стороны сервера о критических изменениях или выполнении ордеров |
Помимо перечисленных особенностей для данного интерфейса ограничена максимальная частота взаимодействия — не более 100 запросов в секунду от каждого пользователя.
Сценарии использования
Выбор протокола для взаимодействия с системой должен быть обусловлен характером решаемой задачи и интенсивностью торговых операций. Ниже представлен ряд сценариев работы с системой, при которых допустимо или недопустимо использовать HTTP API:
| Допустимо | Недопустимо |
|---|---|
| Первичная загрузка полных справочников торговых инструментов и площадок | Имитация потока обновлений рыночных данных в реальном времени через частые повторные запросы |
| Получение точечных данных об инструменте или позиции | Выгрузка полного объёма данных без ограничений и фильтрации |
| Получение исторических данных за ограниченный период | Выгрузка больших объёмов или регулярный запрос одних и тех же исторических данных |
| Точечное выставление заявок, объединение их в группы или снятие всех заявок одним запросом | Высокочастотное выставление и снятие заявок отдельными запросами |
| Сверка локального состояния портфеля и позиций после сбоев | Мониторинг быстроизменяющихся параметров, таких как биржевой стакан или текущие котировки |
Для сценариев высокоинтенсивного взаимодействия с минимальной задержкой используйте WebSocket API.
Ряд справочных данных можно получить с помощью GraphQL API.
Рекомендации
Независимо от характера задачи, для обеспечения стабильности взаимодействия и снижения риска блокировки доступа придерживайтесь следующих правил:
- Кэшируйте статические данные. Сохраняйте справочники локально и обновляйте их не чаще одного раза в торговую сессию или при получении уведомления об инвалидации кэша.
- Соблюдайте лимиты нагрузки. Не превышайте порог в 100 запросов в секунду. Для снижения интенсивности используйте механизмы
throttlingна стороне клиента. - Оптимизируйте выборки. Используйте параметры фильтрации и пагинации, чтобы запрашивать только необходимый объём данных. Избегайте регулярной выгрузки полных списков без фактической необходимости.
- Управляйте токенами доступа. Переиспользуйте полученный токен в течение всего срока его жизни (30 минут) вместо генерации нового под каждый запрос.
Комбинируйте все доступные интерфейсы системы для максимально эффективного решения стоящих перед вами задач.
Игнорирование рекомендаций и/или использование HTTP API не по назначению приведёт к блокировке доступа к системе. Подробнее об этом читайте в статье "Ограничения и рекомендации".