invest-openapi
invest-openapi copied to clipboard
Tinkoff
Как правильно отследить исполнение Limit Order'а?
Допустим я выставляю заявку, мне возвращается её номер - что с ним дальше делать? Streaming не поддерживает ни LimitOrder, ни Operation, значит нужно постоянно запрашивать список операций через restapi, а там жёстко фильтрация по figi. То есть если есть много заявок, то с ограничением на 120 запросов информация будет сильно задерживаться (допустим для 10 заявок не чаще чем раз в 5 секунд).
Если нельзя в разумное время добавить стриминг, то может хотя-бы дадите возможность получать список всех операций за период, без фильтрации по figi?
В ту же копилку: как связать операцию и заявку? То есть если есть две заявки на одну и ту же бумагу, как определить к какой относится операция?
И как получить полный список заявок, как активных, так и нет?
Стриминг изменения статуса заявок https://github.com/TinkoffCreditSystems/invest-openapi/issues/87
И как получить полный список заявок, как активных, так и нет?
https://github.com/TinkoffCreditSystems/invest-openapi/issues/51
как связать операцию и заявку? То есть если есть две заявки на одну и ту же бумагу, как определить к какой относится операция?
Подумаем над реализацией
Стриминг изменения статуса заявок #87
Так там и написано что сроки неизвестны. Вот и хотелось бы чтобы хотя бы запросить все операции за период времени.
И как получить полный список заявок, как активных, так и нет?
#51
Видел. Но у меня для завершённой заявки ничего не вернулось. Там всегда должен возвращаться статус любой заявки, или же только активной?
https://github.com/TinkoffCreditSystems/invest-openapi/issues/51
Задача еще не закрыта
@somescout Вроде бы operation.id == order.Id. Я для теста проверил десяток операций и заявок, все сошлось В итоге без стриминга, коряво и относительно медленно можно трекать исполнение так
- Локально хранить список выставленных заявок
- Каждую секунду получать все открытые заявки (всего 60 запросов в минуту и остается еще 60 на выставление заявок)
- Если вдруг заявка пропала - то идти в операции по operation.id == order.Id и разбираться что произошло - отмена, исполнение, частичное исполнение, частичное исполнение + отмена.
А точно ли operation.id == order.Id? Это гарантируемое поведение?
Без стриминга с подпиской на все операции и ордера реально очень неудобно. Приходиться делать кучу ненужных рест-запросов, перегружая сервера.
@ProgrammingLife . Я сделал проверку на паре сотен заказов и это действительно так. Даже какое то время использовал этот подход, чтобы более точно отслеживать отмену заявок "на грани" исполнения. Все работало хорошо вначале, пока я не стал замечать что иногда операции обновляе.ся с существенной задержкой.. наверно задежрка составляла минуты+ у меня появились подозрения, что некоторые исполнения либо вообще не попадают в операции любо попадают туда с задержой в часы (ну я не стал копать, так что это только подозрения) По поводу нагрузки на сервер: с учетом ограничений на количество запросов, не думаю что что можно даже 1 ядро нагрузить более чем на 5%. Некоторый итог (я использую .net сборку):
- При всей моей лояльности к банку, API сильно некачественное. Единственное где его можно использовать - это написать мобильное приложение, где в случае какой то проблемы, пользователь поймет что получилось, а что нет + человек просто может не заметить некоторые странности (не)исполнения заявок
- Тестовый сервер это просто шутка. Его поведение настолько ущербно-ограниченое, что проще тестировать на дешевых акциях.
- Все же побаловаться для хобби проекта пойдет, но ошибочное поведение АПИ будет огорчать очень сильно
- Апи не подходит для написание нормального бота вот почему: 4а. Стриминг стакана регулярно работает неправильно (10+ раз в день, при условии что я не сижу и не мониторю бота), особенно в моменты интенсивной торговли. 4б. Что то мутное происходит с исполнением заявок, заявка на покупку попадает в обалсть стакана на продажу (в мобильном приложении тоже видно), но может не исполнится. Есть подозрение, что заявки варятся где-то на серверах Тинькова и пытаются закрыться с заявками других пользователей Тинькова. Но если это так - то это должно работать незаметно и польователь не должен чувствовать разницы. А может это тоже проблемы стакана. 4в. Если в момент отмены или создания заявки, что то пошло не так, то невозможно понять была ли заявка создана/отменена (с учетом что определенно что то не так с операциями тоже). 4г. Я сейчас играю с 6 инструментами, думаю минимум я отхватываю пару сотен ошибок при вызове АПИ. Может это не страшно, но это нервирует и так не должно быть. 4д. Нельзя быстро понять, что заявка исполнена. Даже если читать заявки каждую секунду, видно что заявка должна была быть исполнениа, но вот апи ее возвращает и говорит что она даже не начала исполняться. (опять же может проблемы в чем то описанном выше). Я не говорю про HFT, но задержка может достигать десятка секунд (касается условно 10% заявок при интенсивной торговле), по мне так это перебор для любой компьютерной системы.
Наболело за двенедели мучений :)
@llotar испытываю такие же проблемы. Плюс могу от себя добавить:
- При срабатывании buy limit ордера следующие несколько секунд (иногда одну, иногда на протяжении 10 секунд) при запросе текущих позиций (/portfolio) видно что ордер исполнился, но если запросить все текущие открытые ордера (/orders), то он всё ещё висит не исполненным. Как будто данные дергаются из разных баз, которые не синхронизированы.
- После срабатывания buy limit ордера и полном его исполнении следующие несколько секунд при запросе текущих позиций (/portfolio) у данной позиции почему-то бывает AveragePositionPrice: null и AveragePositionPriceNoNkd: null
- Частые 500 и 503 ошибки (Service temporarily unavailable.)
@llotar с учетом всех обозначенных проблем, есть ли на рынке открытое АПИ (у брокера с нормальными тарифами) лучше чем у тинькова в настоящий момент?
@a0s у ItCapital апи помощнее, но оно переусложнено и там есть проблемы с надежностью. Но там в теории можно написать обертку, которая эти проблемы решит. Если оценить по 10 бальной шкале: тинькофф - 5, itcapital - 6. Оба плохи по своему:) а больше апи вроде ни у кого нет, видать отсутствие конкуренции расслабляет.
@llotar , заявка на покупку может попадать в область стакана на продажу из-за особенностей работы СПб биржи, в частности из-за наличия двух пулов ликвидности. Это не проблема API. Все остальное сильно расстраивает, конечно =((
