Объяснение API для торговли на Форекс: REST, WebSocket, FIX и MT5

RESTFIXВебСокет

1. Приложение отправляет заказ брокеру через REST.
2. Поставщик ликвидности отправляет цены брокеру, а WebSocket поддерживает приложение в актуальном состоянии.
3. Брокер проверяет заказ и передает его на торговую платформу.
4. Маршрутизатор исполнения отправляет заказ поставщику ликвидности через FIX.
5. Заполнение возвращается брокеру, затем приложение получает подтверждение через WebSocket.

Точный маршрут зависит от брокера. Некоторые платформы предоставляют торговые команды через REST. Другие передают как запросы, так и события через WebSocket или сырой TCP. Брокер MT5 может использовать шлюз, мост или внутреннюю торговую логику вместо отправки каждого ордера непосредственно поставщику ликвидности.

Таким образом, диаграмму следует рассматривать как архитектурный шаблон, а не как обещание, что каждый брокер обрабатывает сделку одинаково.

Что такое REST API в торговле на форекс?

REST API предоставляет ресурсы через HTTP. Клиент отправляет запрос на конечную точку, а сервер возвращает ответ.

Типичные вызовы выглядят так:

• GET /accounts/417 для загрузки аккаунта;
• GET /orders?status=open для получения открытых заказов;
• GET /candles?symbol=EURUSD&timeframe=1h для запроса исторических баров;
• POST /orders для отправки заказа;
• DELETE /orders/8921 для запроса отмены.

Точные URL и методы зависят от провайдера. Основная идея заключается в запросе и ответе. Сам протокол HTTP является статeless, что означает, что каждый запрос может быть понят самостоятельно. Спецификация HTTP определяет семантику методов, кодов состояния и ответов.

Где REST работает хорошо

REST является практичным выбором для данных, которые изменяются только по запросу:

• профили аккаунтов и разрешения;
• доступные инструменты и настройки контрактов;
• депозиты, вывод средств и отчеты;
• исторические заказы, сделки и свечи;
• настройки стратегии;
• создание или отмена заказов, когда API поддерживает торговлю.

Легко проверять, регистрировать, кэшировать и интегрироваться с обычной веб-инфраструктурой. Большинство команд разработчиков уже знают, как работать с HTTP и JSON.

Где REST начинает испытывать трудности

REST не является изначально медленным. Хорошо построенный REST API может отвечать достаточно быстро для многих торговых рабочих процессов. Проблема возникает, когда клиент должен задавать один и тот же вопрос сотни раз:

Изменилась ли пара EUR/USD?

Мой заказ выполнен?

Мой маржин изменился?

Такое опросы создают повторяющиеся запросы, заголовки и работу сервера. Это также может оставлять промежутки между опросами. Если приложение запрашивает цену раз в секунду, оно не знает, что произошло между этими запросами.

Я использую REST для снимков и команд. Я не использую опрос в качестве основного источника состояния живой торговли, когда существует соответствующий поток событий.

Что такое WebSocket API в торговле на форекс?

WebSocket создает одно постоянное, двустороннее соединение между клиентом и сервером. После открытия рукопожатия любая сторона может отправить сообщение, не дожидаясь нового HTTP-запроса. Это поведение определяется в протоколе WebSocket.

В торговом приложении клиент может подписаться на EURUSD один раз. Затем сервер отправляет каждое разрешенное обновление котировок через открытое соединение. В том же потоке могут передаваться подтверждения заказов, исполнения, изменения баланса и события маржи.

Где WebSocket работает хорошо

API WebSocket для форекс подходит для данных, которые постоянно изменяются:

• цены на покупку и продажу;
• обновления графиков;
• глубина рынка;
• прием, отказ и исполнение заказов;
• изменения в позициях и учетах;
• предупреждения о марже;
• статус торговой сессии.

Клиент получает изменения вместо того, чтобы постоянно их запрашивать. Это уменьшает опросы и делает интерфейс более живым.

Открытое соединение недостаточно

WebSocket сам по себе не делает торговое приложение надежным.

Телефон переключается на другую сеть. Ноутбук переходит в спящий режим. Прокси закрывает неактивное соединение. Сервер перезагружается. Сообщения могут перестать поступать, прежде чем интерфейс это заметит.

Я ищу пять механизмов восстановления:

1. Сердцебиение. Клиент должен знать, жива ли связь.
2. Состояние устаревших данных. Интерфейс должен прекратить отображение старой цитаты как актуальной.
3. Восстановите соединение и повторно подпишитесь. Клиенту необходимо восстановить каждый требуемый поток.
4. Снимок плюс обновления. После повторного подключения загрузите текущий REST-снимок перед применением новых событий.
5. Последовательность или курсор. Если API предоставляет идентификаторы событий, используйте их для обнаружения пропусков и дубликатов.

Что такое FIX API в торговле на Форекс?

FIX означает Financial Information eXchange. Он определяет сообщения, которые финансовые системы используют для общения о заказах, исполнениях, котировках, рыночных данных и сессиях.

Новый заказ, например, следует общему типу сообщения с именованными полями для деталей, таких как инструмент, сторона, количество, тип заказа и ID клиентского заказа.

FIX является общим между:

• брокеры и поставщики ликвидности;
• брокеры и биржи или другие площадки;
• институциональные клиенты и брокеры;
• системы управления заказами и системы исполнения.

Почему компании используют FIX

FIX предоставляет обеим сторонам общий финансовый язык и дисциплинированный способ управления подключением. Это не автоматически самый быстрый API; производительность все еще зависит от движка, сети и настройки контрагентов.

Сессия FIX отслеживает номера последовательности сообщений. Если одна сторона получает сообщение 208 после сообщения 206, она может обнаружить, что 207 отсутствует, и запросить повторную отправку. Сердцебиения и тестовые запросы помогают обеим сторонам контролировать сессию.

Это имеет значение, когда сообщения представляют заказы и их исполнение. “Соединение восстановлено” недостаточно. Оба системы должны согласовать, какие сообщения были обработаны.

Что не решает FIX

FIX не удаляет интеграционную работу.

Две стороны всё ещё должны согласовать:

• версия FIX и поддерживаемые сообщения;
• обязательные, дополнительные и пользовательские поля;
• имена символов и идентификаторы инструментов;
• поддерживаемые типы заказов и значения времени действия;
• точность цены и количества;
• торговые сессии и окна обслуживания;
• правила сброса последовательности и повторной отправки;
• тестовые случаи сертификации;
• сетевая безопасность и разрешенные IP-адреса.

Я никогда не принимаю “FIX поддерживается” как полный ответ по интеграции. Я запрашиваю спецификацию контрагента и план сертификации. Стандарт с различными правилами полей с каждой стороны все равно требует сопоставления и тестирования.

Что означает “MT5 API”?

MetaTrader 5 — это платформа, а не один API протокол. MetaQuotes перечисляет несколько интерфейсов для брокеров, включая Manager, Gateway, Report, Server и Web API. Каждый из них выполняет свою роль в среде MT5.

Менеджер API

API менеджера предназначен для административных и управленческих инструментов на стороне брокера. Брокер может использовать его для создания внутренних утилит, связанных с учетными записями, группами, торговыми операциями и администрированием платформы.

Это не тот же продукт, что и API-ключ розничного трейдера. Доступ, лицензирование и поддерживаемые операции принадлежат настройкам MetaTrader брокера.

API шлюза

API шлюза предназначен для подключения MetaTrader 5 к внешним торговым системам и потокам данных. MetaQuotes описывает шлюзы как плагины платформы, которые обрабатывают взаимодействие с биржами или другими подключенными системами.

Это гораздо ближе к рыночной связи, чем REST-эндпоинт, ориентированный на трейдеров.

Веб, отчеты и серверные API

MetaQuotes описывает Web API как интерфейс для связывания платформы с веб-ресурсами и услугами брокера. Report API расширяет серверную отчетность. Server API позволяет операторам платформы добавлять функции торгового сервера и сервера истории.

Их названия могут выглядеть самоочевидными, но объем и доступность необходимо проверять в лицензии брокера и технической документации.

MQL5

MQL5 — это язык и программная среда, используемая внутри MetaTrader 5. Трейдеры и разработчики создают советников, индикаторы, скрипты и службы, которые работают с терминалом.

Это родной маршрут для автоматизированной стратегии, которая нуждается в данных графиков, индикаторах и торговых функциях внутри MT5. Это не протокол брокер-к-поставщику ликвидности.

Интеграция MetaTrader 5 с Python

Официальный MetaTrader5 пакет для Python позволяет программе на Python считывать данные и отправлять торговые запросы через терминал MetaTrader 5. Важные слова – через терминал.

Официальная документация Python утверждает, что пакет напрямую взаимодействует с терминалом, используя межпроцессное взаимодействие. Он не предоставляет произвольному облачному сервису прямое соединение с сервером брокера MT5.

Это различие меняет развертывание. Стратегия на Python требует совместимой терминальной среды, сессии учетной записи, мониторинга и плана для перезапусков терминала. Она не должна быть спроектирована так, как будто pip install MetaTrader5 создает API брокера на стороне сервера.

Один заказ может проходить через несколько API

Предположим, трейдер покупает 100,000 единиц EUR/USD в мобильном приложении брокера.

1. Приложение загружает учетную запись, спецификацию символов и разрешения через REST.
2. Он получает текущую ставку и предложение через WebSocket.
3. Трейдер нажимает “Купить”. Приложение отправляет команду заказа с уникальным идентификатором клиентского заказа.
4. Служба оценки рисков брокера проверяет маржу, лимиты и состояние рынка.
5. Торговая платформа принимает или отклоняет заказ. Эта платформа может быть MT5.
6. В зависимости от модели исполнения брокера, внешнее воздействие может быть отправлено поставщику ликвидности через FIX, шлюз или другой коннектор.
7. Отчеты об исполнении возвращаются через стек.
8. Приложение получает обновленный заказ, позицию и баланс через свой поток событий.

REST не конкурировал с FIX в этой последовательности. Они работали на разных границах.

Случай с тайм-аутом, который выявляет слабый API

Сложная часть API заказов заключается не в отправке запроса. Дело в том, чтобы знать, что произошло, когда ответ исчезает.

Предположим, что приложение отправляет эту инструкцию:

Купить EURUSD, clientOrderId = mobile-84721

Время ожидания запроса истекло. Есть две возможности:

• брокер никогда это не получил;
• Брокер это принял, но ответ не дошел до приложения.

Слепая отправка одной и той же сделки снова может создать две позиции.

Более безопасный рабочий процесс заключается в следующем:

1. Сохраните тот же идентификатор заказа клиента.
2. Запросите авторитетное состояние заказа или дождитесь события заказа.
3. Позвольте серверу отклонять или дублировать повторяющуюся команду с тем же идентификатором.
4. Согласуйте окончательный заказ и заполните записи перед тем, как включить другую попытку.

Вот почему я спрашиваю поставщиков API о идемпотентности, прежде чем спрашивать о скорости запросов заголовка. Быстрый конечный пункт, который может дублировать финансовое действие после таймаута, не является хорошим торговым конечным пунктом.

REST против WebSocket против FIX против MT5 по использованию

Требование	Интерфейс, который я бы проверил первым	Причина
Веб-сайт брокера, отображающий историю счета	REST	Простые запросы, знакомая аутентификация и четкие ответы
Живая наблюдательная список в веб- или мобильном приложении	WebSocket	Котировки приходят как события без постоянного опроса
Ввод розничного заказа из пользовательского приложения	REST команда плюс статус WebSocket	Четкий процесс подачи с живым подтверждением и обновлениями выполнения
Соединение брокера с поставщиком ликвидности	FIX или сертифицированный коннектор поставщика	Стандартный порядок и рабочий процесс исполнения между торговыми системами
Администрирование брокера вокруг MT5	MT5 Manager API	Создан для управления утилитами на стороне платформы
Пользовательское соединение MT5 с торговой площадкой	MT5 Gateway API или протестированная настройка моста/шлюза	Разработано для рыночной связности платформы
Экспертный советник, работающий в MT5	MQL5	Нативная автоматизация терминала и среда тестирования
Анализ и исполнение на Python через терминал MT5	Пакет Python для MetaTrader 5	Предоставляет доступ Python к данным терминала и торговым функциям
Исторический исследовательский набор данных	REST или экспорт больших данных	Проще постраничная навигация, диапазоны дат и повторяемое извлечение

Таблица является отправной точкой. Окончательный выбор зависит от фактического API провайдера, лимитов скорости, аутентификации, поддерживаемых типов заказов и гарантий обслуживания.

Вопросы, которые я задаю перед выбором API для торговли на форекс

Данные рынка

• Является ли поток по каждому тику, консолидированным или выборочным?
• Генерируются ли временные метки бидов и асков на источнике или при доставке?
• Включает ли поток номера последовательностей?
• Как клиент восстанавливает данные после отключения?
• Версионируются ли спецификации символов при изменении настроек контракта?

Заказы

• Существует ли уникальный идентификатор заказа клиента?
• Являются ли команды создания и отмены идемпотентными?
• Может ли API сообщать о частичных выполнениях и множественных отчетах о выполнении?
• Какой запись является авторитетной после таймаута?
• Как представлены отклоненные, истекшие и замененные заказы?

Операции

• Каковы ограничения на запросы, подписки и соединения?
• Являются ли демонстрационные и рабочие среды поведенчески эквивалентными?
• Существует ли страница статуса и уведомление о запланированном обслуживании?
• Можно ли сопоставить логи между клиентом, брокером и площадкой?
• Как версионируются и объявляются критические изменения?

Безопасность

• Какие разрешения могут быть ограничены для приложения или токена?
• Как происходит ротация и отзыв учетных данных?
• Поддерживаются ли IP-белые списки, TLS и отдельные производственные учетные данные?
• Может ли один сервис читать данные без получения разрешения на торговлю?
• Каждое привилегированное действие записывается в журнал аудита?

Ответы говорят мне больше, чем ярлык на API. Два REST API могут различаться гораздо больше по практическому качеству, чем REST и WebSocket.

Что должен решить брокер перед интеграцией

Проект API обычно становится сложным, когда права собственности неясны.

Определите эти моменты перед началом разработки:

1. Система учета. Какая система отвечает за заказы, исполнения, балансы и позиции?
2. Порядок событий. Как обрабатываются дубликаты, поздние сообщения и обновления вне порядка?
3. Восстановление. Какой снимок загружается после повторного подключения и с какого курсора продолжаются события?
4. Границы риска. Какие проверки проводятся перед тем, как заказ поступит на платформу или площадку?
5. Модель символа. Кто сопоставляет имена, размеры контрактов, сессии и точность цены?
6. Аудиторский след. Может ли поддержка отслеживать одно действие клиента от приложения до окончательного отчета о выполнении?

Здесь решение платформы становится операционным решением. Инфраструктура брокера Quadcode объединяет торговую платформу, клиентские приложения, CRM, бэк-офис, риск и интеграции в одной среде. Необходимые REST, потоковая передача, MT5 или ликвидностные подключения все еще должны быть прописаны в дизайне решения и протестированы на основе собственных ордеров брокера.

Окончательный ответ

Используйте REST для четких запросов, снимков и записей. Используйте WebSocket, когда приложение должно получать живые изменения. Используйте FIX для стандартизированной торговой связи между профессиональными системами. Используйте соответствующий интерфейс MT5, когда MetaTrader 5 является частью платформы.

Большинство forex продуктов требует комбинации. После сбоя в сети надежная архитектура может ответить на три вопроса: Был ли заказ получен? Был ли он выполнен? Согласны ли теперь все подключенные системы с результатом?