FIX API - некий условный стандарт. Слово "стандарт" подходит лишь по причине, что его используют в обмене информацией между собой крупные участники рынка. "Условный" - каждый его реализует, как вздумается. Это значит, что Gate на LP1 не будет работать с LP2, хоть оба используют FIX API. Выявление особенностей и различных тонкостей реализации FIX API в каждом LP - немалая работа.
FIX - API RealTime-данных, поэтому это еще и некий протокол, отличающийся своей простотой: огромный поток голых текстовых сообщений. Это жутко неоптимально и требует хорошего канала связи. Когда этот поток идет от одного источника - не вызывает особых проблем. Но когда идет агрегация от многих - тут вопросы производительности всей системы играют очень важную роль.
FIX API довольно неустойчив. Это значит, что имеется возможность заспаммить торговый сервер LP. По правде говоря, весь институциональный рынок в техническом плане находится в удручающем состоянии. Зажрались от отсутствия серьезной конкуренции. Рубят стабильно деньги и не переживают.
Поэтому давно зрел вопрос, когда и кто даст им по морде технологическим преимуществом и, соответственно, лучшими торговыми условиями.
В этом смысле, например, LMAX хоть немного расшевелил этих ленивцев.
Говоря же о FIX API - это жутко неоптимальный API, который массово давать - подписать себе приговор. Он дается только крупным игрокам и выборочно. Тем, кому это, действительно, надо. У кого уже есть серьезная техническая инфраструктура. Как правило, это различные LP, хэдж-фонды и т.д. Вообщем, таких клиентов < 1000.
А при массовом API речь идет уже о десятках и сотнях тысяч потенциальных клиентов. Поэтому такой API должен быть продуман и вылизан. Должны быть разработаны свои протоколы передачи данных. Решены вопросы доставки всей RealTime информации без пропусков.
Вообщем, должна быть великолепная ИТ-команда, чтобы все продумать и реализовать.
Для массовости API должен быть не только RealTime, но и History. При этом в идеале History должен содержать данные по времени, тикам и даже Level2.
Желательно иметь некий SDK тестера, с помощью которого можно создать GUI тестера. Короче, при правильном подходе это должен быть продукт, аналогов которому нет и никогда не было в FOREX-индустрии.
ForexConnect API имеет тиковую историю, SDK тестера (+GUI) и хорошую производительность. Однако, при выборе, повторюсь, надо выбирать тот вариант, который принесет бОльшую прибыль.
Поэтому, когда я сравниваю FXOPEN+MT4 и FXCM+ForexConnect, делаю выбор в пользу первого, несмотря на тормозной MT4 и отличный ForexConnect.
Если клиенсткий (есть еще и брокерский) API пишет сторонняя команда, только теоретически знакомая с торгами, то вероятность написания хорошего продукта у них низка.
И наоборот, если API пишут отличные алготрейдеры (в идеале HFT-шники) и/или практики технической торговой инфраструктуры (действующие агрегаторы), то результат с высокой вероятностью должен быть достойного качества.
Как пример этого утверждения, можно сравнить MT4-5 и StockSharp. Кстати, архитектурно StockSharp очень продуман. Но, к сожалению, не подходит для FOREX. Несмотря на это, желающим быть на передовой, рекомендовал бы заняться изучением/повторением языка C#.
Не забывайте, что для алготрейдера API - это инструмент. Чем лучше инструмент, тем больше возможностей. Но построить "дом" с помощью этого инструмента - основная задача алготрейдера. Поэтому исследовать и исследовать рынок. В этом деле вам очень может помочь Python.
P.S. Из нескольких постов получилась небольшая серия ликбеза. 100%, что в мною написанном содержатся определенные неточности и даже ляпы. Но лучше так, чем никак.