Список проголосовавших за комментарий "Тут комрады задали вопросы, что именно в API IB плохо.<br/> <br/> Вот некоторые пункты (список далеко не полный):<br/> — документация неполная и не всегда соответствует реальности; т.е. периодически натыкаешься на ситуацию, когда реальное поведение не соответствует тому, что описано; поэтому доверять документации нельзя, надо все проверять экспериментально и изучать непосредственно их код<br/> — встречаются параметры методов, которые просто не описаны в документации<br/> — API сильно морально устарело (сейчас такие API принято делать асинхронными, а тут используется очень старая концепция вызова методов-коллбеков) и страдает от накопившихся странных решений; полагаю, что это следствие их желания максимально поддерживать обратную совместимость, хотя на практике им это не всегда удается<br/> — в API нет единообразия; например, некоторые методы принимают параметры в виде отдельных элементарных типов данных (типа Open, Hihj, Low, Close по отдельности), а некоторые в виде сложных типов (например, те же значения, но агрегированные как Bar)<br/> — странности с типами данных: даты зачастую передаются строками, но иногда в виде чисел Unix Epoch; часто числовые параметры или параметры типа Enum тоже передаются в виде строк; bool значения иногда передаются в виде магических чисел; цены представлены в виде типа double, а не decimal<br/> — обратка ошибок просто дикий треш: в API представлено 3 перегрузки метода error(), которые вызываются в случае ошибок, предупреждений, нотификаций и просто информационных сообщений; все это валится в одну кучу и клиенту API самому надо разгребать этот поток, чтобы понять, какая ошибка (и ошибка ли?) к чему относится; в документации описаны не все возможные ошибки, т.е. всегда есть вероятность, что прилетит что-то новое и неведомое<br/> — некоторые методы начинают себя вести заметно и неожиданно по-другому, в зависимости от параметров: например, метод запроса исторических свечей в случае запроса дневных свечей начинает обрезать интервалы по границам сессии и странно себя ведет, если на границе сессии нет данных<br/> — прямо в документации к методу выставления заявки написано, что в качестве реакции на это могут приходить 4 разных коллбека, но некоторые из них не гарантируются; т.е. чтобы надежно отработать выставление заявки и трекинг сделок по ней приходится постоянно учитывать, что какой-то из коллбеков может не прийти, а порядок срабатывания не гарантирован<br/> — TWS принудительно выключается раз в сутки; отключить это поведение нельзя, можно только включить режим автоперезапуска после выключения<br/> — при выключении TWS никак не сообщает это клиентам API; клиенты вообще не замечают, что что-то выключилось<br/> — на следующей попытке вызвать что-то в API внутри API вылетает исключение, которое молча давится, а вместо исключения вызывается метод коллбек; этот метод вызывается и при нормальном дисконнекте тоже, т.е. различить две ситуации невозможно<br/> — также этот метод вызывается дважды подряд, что является явным багом; нельзя реагировать на первый вызов, чтобы начинать делать реконнект, т.к. может прийти следом второй; но второй вызов происходит не во всех ситуациях, т.е. его может вообще не быть<br/> — если пытаться переконнектится к TWS после перезапуска, то ошибки соединения на старте, если сокет еще не готов, выбивают исключение, оставляющее объекты API в неконсистентном состоянии; при этом это исключение не вылетает из метода, а тоже посылается в отдельный метод для обработки ошибок, т.е. все преимущества исключения убиваются и делается максимально неудобно, т.к. невозможно простым способом в точке вызова получить ошибку, надо писать костыльные обвязки лишнего кода только для обслуживания этой фигни<br/> — т.е. иногда сетевые ошибки молча давятся, иногда прилетают в виде сообщений об ошибках в общей куче, а иногда вылетают исключениями, но даже когда это происходит с исключением, это сделано криво<br/> — помимо всего этого есть еще отдельный зоопарк ситуаций, когда отваливается соединение между TWS и серверами IB; все эти случаи работают по разному и никак между собой не согласованы; что приводит к высокому риску разнообразных race condition и дедлоков, т.к. это еще и в различающихся потоках происходит в зависимости от ситуации<br/> — если во время работы TWS изменяется IP адрес компьютера, то молча и окончательно отваливваются реалтайм потоки данных, т.е. перестают присылаться реалтайм свечи, например; помогает только ручной перезапуск соединения TWS"