Bitcoin Forum

Коллеги, мы получили от вас запрос на создании отдельной ветки по API.
У нас есть стандартный API для торговых роботов, совместимый с BTC-e.

У меня собственно, те же самые вопросы для начала, что уже задавал в ваших ветках:

Совместимость с АПИ БТЦе вовсе не полная.

1. Не работало в АПИ2 ограничение количества ордеров в стакане по запросу стакана.
         На БТЦе - такое работает. На ГОК не работало.
         Получаю ордера тысячами, хотя мне нужен десяток ближайших. Пример приводил.

2. На БТЦе уже год как работает АПИ3. Намного экономичнее и удобнее в плане трафика.
         Какие тут планы ? Ссылку на их АПИ3 давал.

3. Была обещана возможность оперирования средствами при помощи АПИ.
         Что то по срокам можно говорить ?

Вывод через АПИ пока не документирован. Можем дать, если у вас серьезные намерения и остатки нормальные на счете.

1. Ограничение ордеров пока еще в процессе.

Например лог сырых данных (это все события - размещение ордеров, отмена ордера, модификация объема ордера, факты пересечения ордеров) может иметь следующий формат (простая таблица с полями):
* идентификатор события - для событий типа order/cancel - это идентификатор отложенный сделки, для trade - просто идентификатор, я рекомендую здесь использовать единый сиквенс
* время - пожалуйста, не экономьте на точности, выдавайте microtime(true) хотя бы с 3 знаками после запятой (а в protobuf используйте float или даже int64 но в микросекундах)
* валютная пара - ltc_usd/btc_usd/... правильнее идентфикатор и выдавать информацию по ним отдельным запросом
* тип события - trade/order/cancel, order - клиент разместил ордер, cancel - отменил ордер, trade - факт пересечения одной сделки пользователя с другой, т.е. если клиент разместил ордер по рынку, в лог попадут как минимум две записи, одна order, и одна или несколько trade. Есть еще желательное действие move, но о его вводе я уже не мечтаю.
* тип ордера - bid/ask, это направление сделки относительно ее иннициатора, конечно можно так же завести значение в справочнике или boolean
* идентификатор ордера - для событий trade, это идентификатор сделки, с которой произошло пересечение (сейчас у вас это order_id), для событий типа order это значение пусто или равно идентификатору события если ордер создается, а для событий отмены ордера - идентификатор отменяемого ордера
* объем события - для order это объем всей сделки, для cancel - объем остатка сделки, для trade - объем пересечения (собственно объем самой операции)
* цена сделки

Полный лог этих данных полностью самодостаточен и позволит восстановить состояние биржевого стакана и историю торгов на любой момент. Для оптимизации этого процесса можно выдавать периодические дампы (например раз в сутки) того же стакана.
Если вы не готовы выдавать его по websocket (но это надо, обязательно), сохраняйте в статических файлах, разбивая по интервалам времени (часы к примеру, а позже и на минуты), в этом случае трейдеры будут периодически загружать только маленький текущий файл. Нагрузка на статику, в отличии от динамически генерируемых данных, отлично горизонтально масштабируется, на их отдачу можно выделить несколько серверов, даже разнесенных географически, и только один файл должен отдаваться самой торговой платформой - текущий.
Если вы опасаетесь, что трейдеры получат излишнюю информацию об идентификаторах, то замените их на новые - привязанные к ордер+цена, соответственно объедините ордера с одной ценой (cancel записи позволяют указать отмену части ордера).
Цены и объемы в виде целых чисел с фиксированной точностью, точность описывается так же в отдельном запросе к бирже (сделать один файл на бирже, описывающий список валютных пар, точности, значения идентификаторов и т.п.)

Про protobuf, люди, мы в каком веке? хватит уже роботам общаться в human readable форматах, кои на порядок более жрущие по ресурсам чем их бинарные аналоги, google protobuf есть чуть ли не под все популярные платформы и не только высокоффективный но и идеологически верный, неизменная логика, описывающая структуру данных, просто компилируется в виде классов на выбранном вами языке программирования.

p.s. я нечего не изобретаю, похожие логи выдают некоторые (или может даже все) мебанковские валютные биржи, только не всем клиентам, слишком этот поток тяжелый (я не согласен кстати, какие то гигабайты в месяц - ничто)

Добавили возможность получения суточного объема.
Можно спросить у саппорта, как его запрашивать...

Вообще, это вроде стандартный запрос возвращает такие данные.
Или вы что то новенькое придумали ? Не хотелось бы....

А насчет саппорта, вроде и тему в разделе Кодеры завели специально,
что бы по 100 раз одними и теми же вопросами саппорт не грузить.

Тут и кодеры и очень хорошо если саппорт будет. Зачем ему куда то писать, не умно.
Потери времени. И у нас - и у вас.

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

У нас есть стандартный API (https://goc.io/docs/gocio_trade_api.pdf) для торговых роботов, совместимый с BTC-e.
Будем рады услышать ваши вопросы и предложения, и с еще большой радостью на них ответим!

Совместимость с АПИ BTC-e отсутствует. Провокация. Жаль.

https://btc-e.com/api/3/documentation#main

https://btc-e.com/api/3/ticker/btc_usd:
{
   "btc_usd":{
      "high":109.88,
      "low":91.14,
      "avg":100.51,
      "vol":1632898.2249,
      "vol_cur":16541.51969,
      "last":101.773,
      "buy":101.9,
      "sell":101.773,
      "updated":1370816308
   }
   ...
}


{
"ticker":
{
"online":true,
"high": 25451.7601,
"low":24910.1029,
"avg":25180.9315,
"vol":4036488.14986,
"vol_cur":178.52999851,
"last":25409.1700,
"last_change":2.7029,
"buy":25409.1700,
"sell":25100.9812,
"updated":1388266919,
"server_time":1388309961
}
}

В версии БТС-е АПИ 2 нет описания запроса ticker. Не так ли?
Такой запрос только в АПИ 3. Не ошибаюсь? Потому с АПИ 2 тоже не совместимо.

Не путайте народ.

У меня собственно, те же самые вопросы для начала, что уже задавал в ваших ветках:

Совместимость с АПИ БТЦе вовсе не полная.

1. Не работало в АПИ2 ограничение количества ордеров в стакане по запросу стакана.
         На БТЦе - такое работает. На ГОК не работало.
         Получаю ордера тысячами, хотя мне нужен десяток ближайших. Пример приводил.

Просим любить и жаловать https://goc.io/api/btc_rur/depth/?25
Так, вы можете ограничивать количество получаемых строк в стакане.

Еще бы стаканы по списку одним запросом выдавались, вообще экономично было бы.

Примем во внимание, посмотрим, что сможем сделать.

Просим любить и жаловать https://goc.io/api/btc_rur/depth/?25
Так, вы можете ограничивать количество получаемых строк в стакане.

API для торговли кодами есть?