REST или WebSocket: как дать торговому боту реальное время

Торговый бот, который получает цены по REST API раз в секунду, похож на джедая, размахивающего световым мечом по таймеру. Вроде стараешься, но удары всё время уходят в пустоту: резкие движения цены проходят мимо. Это ровно то, что случилось со мной на первом серьёзном боте. Логика стратегии была чистой, а данные безнадёжно устаревали.

REST-опрос — это вопрос «какая цена прямо сейчас?» с частотой раз в секунду. Ответ вы получаете, но он описывает прошлое. Для алгоритмической торговли прошлое на секунду меньше — почти вечность.

Почему REST-опрос проигрывает

Каждый вызов REST API — это отдельный HTTP-запрос с накладными расходами. К секунде-старой цене добавляются сетевые задержки, обработка запроса, сериализация. Вы ещё не получили ответ, а рынок уже ушёл.

Плюс у API есть rate limit. Если бот опрашивает сервер каждую секунду, он сжигает лимиты впустую. Чем больше символов в стратегии, тем чаще вы упираетесь в ошибки 429.

И ещё один нюанс: приложение без ретрая падает, как только соединение с API обрывается на долю секунды. В WebSocket вы подключаетесь один раз, и вопросы обрыва решаются отдельным обработчиком, а не крашем всего процесса.

Что даёт WebSocket

WebSocket — это постоянный канал двусторонней связи. Открыли соединение, отправили запрос на подписку — и сервер сам присылает каждый тик, каждое изменение стакана, каждое исполнение сделки. Вам не нужно спрашивать. Рынок сам говорит с вами.

Задержка падает до десятков миллисекунд. Вы перестаёте тратить время на HTTP накладные расходы, а бот начинает видеть микро-движения, которые раньше проскакивали мимо. Именно поэтому реальное время — не роскошь, а база для активной торговли.

Как подключить WebSocket: шаги на примере Alpaca

Alpaca подходит для демонстрации: у неё есть и REST, и WebSocket для американских акций. Эндпоинт WebSocket выглядит так: wss://stream.data.alpaca.markets/v2/iex. Работать с ним довольно просто.

1. Открыть соединение с WebSocket-адресом.
2. Аутентифицироваться: отправить JSON с полями action, key и secret.
3. Подписаться на тикеры: передать action: subscribe и список символов для trades.
4. В обработчике сообщений проверять тип сообщения и забирать цену, символ и время.
5. Добавить обработчик ошибок и закрытия. При закрытии — подождать пару секунд и переподключиться.
6. Держать соединение живым пингами с интервалом 30 секунд.

В Python это делается через библиотеку websocket-client. В колбэке on_open сначала отправляете аутентификацию, потом подписку. В on_message разбираете JSON и передаёте нужные поля в стратегию. В on_close не забываете про реконнект.

Сравнение: REST против WebSocket

Когда WebSocket не нужен

Всё зависит от горизонта торговли. Если стратегия держит позиции несколько дней и решает на основе дневных свечей, секундная задержка ничего не меняет. REST API вполне хватит, а настройка WebSocket только добавит хрупкости.

WebSocket нужен интрадей-стратегиям, арбитражу, market making — всему, что реагирует на микро-движения в течение нескольких секунд. Для этого опрос REST — просто убить производительность.

Типичные ошибки при переходе на WebSocket

• Забыли аутентификацию — соединение открывается, но подписка не работает.
• Игнорируете on_close — бот молча умирает при разрыве сети.
• Нет обработчика ошибок — исключение роняет весь процесс.
• Подписались на слишком много тикеров — поток сообщений не успевает обрабатываться, и стратегия захлёбывается.
• Не проверяете данные — иногда приходят опоздавшие сообщения или дубликаты, и это надо чистить.
• Надеетесь, что одно соединение будет жить вечно, без пингов и реконнекта.

Самый простой путь — начать с одного тикера, добавить реконнект и обработку ошибок, потом уже расширять на остальные символы. Так вы быстро увидите, как реальный поток отличается от опроса REST, и поймёте, стоит ли овчинка выделки для вашей стратегии.

В итоге WebSocket — это не магия, а правильный инструмент. Для активных роботов он обязателен, для редких сделок — лишняя сложность. Выбирайте по горизонту торговли, а не по красивым графикам.