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

REST, WebSocket, FIX и MT5 часто представляются как четыре конкурирующих forex API. Это не так.

REST обычно является самым простым способом запроса данных учетной записи, загрузки истории или отправки случайной команды. WebSocket поддерживает открытое соединение, чтобы цены и обновления заказов могли поступать по мере их возникновения. FIX — это стандарт финансовых сообщений, используемый для маршрутизации ордеров, отчетов о выполнении и рыночных данных между профессиональными торговыми системами. MT5 — это торговая платформа с несколькими API для различных задач.

Брокер может использовать все четыре. Мобильное приложение может загружать счет через REST, транслировать цены через WebSocket, отправлять заказ в MetaTrader 5 и перенаправлять внешнюю экспозицию к поставщику ликвидности через FIX. Каждый интерфейс принадлежит к разной части сделки.

Интерфейс	Шаблон коммуникации	Лучшее соответствие	Плохое соответствие
REST API	Клиент отправляет запрос и получает ответ	Потоки входа, учетные записи, символы, история, отчеты и команды с низкой частотой	Непрерывная потоковая передача цен через повторные опросы
WebSocket API	Клиент и сервер поддерживают двустороннее соединение	Живые котировки, глубина, статус заказов и события учетной записи	Долгосрочные исторические запросы и простые административные записи
FIX API	Две торговые системы обмениваются стандартизированными финансовыми сообщениями в рамках управляемой сессии	Поток заказов от брокера к ликвидности, площадке и институциональным клиентам	Простой публичный API для розничного мобильного приложения
MT5 APIs	Несколько интерфейсов вокруг платформы MetaTrader 5	Администрирование брокера, расширения платформы, шлюзы, отчеты и автоматизация терминала	Универсальный протокол, независимый от MT5

Как эти API вписываются в одну систему торговли на Форекс

Я рассматриваю четыре названия как разные уровни.

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

How one forex order moves through the stack

One order. Five steps. From the trader’s app to execution and back.

01Order 02Live price 03Risk check 04Execution 05Confirmation

RESTFIXWebSocket

Trader appBUY 100K EUR/USD

Broker coreORDER #A-18427 / EUR/USD

API gatewayWaiting

Risk enginePending

Trading platform – MT5Ready

Execution routerPending

RESTWaiting for order

Liquidity providerPrice + fill

CRM / automationAccount and client data

Venue / exchangeMarket data and venues

1. The app sends the order to the broker through REST.
2. The liquidity provider sends prices to the broker, and WebSocket keeps the app current.
3. The broker checks the order and passes it to the trading platform.
4. The execution router sends the order to the liquidity provider through FIX.
5. The fill returns to the broker, then the app receives the confirmation through WebSocket.

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

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

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

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

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

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

Точные URL и методы зависят от провайдера. Основная идея заключается в запросе и ответе. Сам по себе HTTP является бессостоянием протоколом, что означает, что каждый запрос может быть понятым самостоятельно. Спецификация 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. Он определяет сообщения, которые финансовые системы используют для общения о заказах, исполнениях, котировках, рыночных данных и сессиях.

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

FIX общепринят между:

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

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

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

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

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

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

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

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

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

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

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

MetaTrader 5 является платформой, а не одним протоколом API. MetaQuotes перечисляет несколько интерфейсов для брокеров, включая 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. Позвольте серверу отклонить или удалить дубликаты повторяющейся команды с тем же ID.
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 является частью платформы.

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