WebSocket проти REST для криптотрейдингу: який API обрати
Використовуйте обидва протоколи, кожен для своїх завдань. WebSocket — це найкращий канал для стрімінгу ринкових даних та оновлень ордерів. REST — найкращий вибір для запитів по рахунку, історії, балансів і фандингу. Торговий бот, побудований лише на одному з них, зазвичай виявляється або повільним, або нестабільним.
У цьому посібнику ми пояснимо, чим ці два протоколи відрізняються на практиці, де кожен із них може підвести та як розподілити обов'язки між ними, щоб виконання стратегії залишалося стабільним навіть при збоях з'єднання, перевищенні лімітів або помилках біржі.
Коротко (TL;DR)
- REST працює за принципом «запит-відповідь»: ви питаєте, біржа відповідає знімком даних. WebSocket — це постійне двостороннє з'єднання, яке надсилає оновлення в реальному часі.
- Використовуйте WebSocket для стаканів (order books), живих цін та статусів ордерів. Використовуйте REST для балансів, історії, депозитів, виводів та звірки даних.
- З'єднання WebSocket надійне лише настільки, наскільки надійна логіка навколо нього: heartbeats, повторна підписка та синхронізація стану після кожного перепідключення.
- Ліміти запитів (rate limits) діють на обидва протоколи, тому вибір впливає на те, скільки даних ви можете безпечно споживати, а не лише на швидкість їх отримання.
- Більшість стратегій для криптоботів (без колокації) не потребують FIX або будь-яких протоколів, окрім REST та WebSocket.
Чим відрізняються ці два протоколи
REST працює як обмін питаннями та відповідями. Ваше програмне забезпечення відкриває HTTP-запит, біржа відповідає поточним станом — це фактично «знімок» даних на конкретний момент. Кожен виклик є незалежним; біржа не пам'ятає попередній запит.
WebSocket працює інакше. Протокол відкриває двосторонню інтерактивну сесію, що дозволяє надсилати повідомлення на сервер і отримувати відповіді, що генеруються подіями, без необхідності постійно опитувати сервер. Після початкового «рукостискання» (handshake) з'єднання залишається відкритим, і будь-яка сторона може надіслати дані в будь-який момент.
Практичні наслідки:
| Властивість | REST | WebSocket |
|---|---|---|
| Модель підключення | Короткочасне, один запит на виклик | Постійне, двостороннє |
| Доставка даних | Pull (ви запитуєте) | Push (біржа надсилає) |
| Затримка на повідомлення | Вища, через накладні витрати на кожен запит | Нижча після встановлення з'єднання |
| Стан (State) | Безстановий (Stateless) | Зі станом (Stateful): підписки, сесії |
| Типове використання | Дані рахунку, історія, фандинг | Стакани, стрімінг цін, виставлення та статус ордерів |
| Основний режим відмови | Ліміти запитів, застарілі знімки | Приховані розриви, переповнення буфера, втрата повідомлень |
Ця таблиця також пояснює, чому питання «що краще» є некоректним. Вони вирішують різні завдання.
Для чого підходить кожен протокол
REST: операційні завдання та верифікація стану
REST ідеально підходить для разових операцій: отримання історії рахунку, перевірка балансів, керування депозитами та виводами. Такі завдання класифікуються як операційні, на відміну від стрімінгів у реальному часі.
REST також має властивість, критичну для систематичних стратегій: відповідь є явним, перевіреним твердженням про стан системи в певний момент часу. Коли боту потрібно підтвердити, чим він насправді володіє або які ордери дійсно відкриті, прямий запит через REST є найнадійнішим джерелом істини.
WebSocket: стрімінг даних та активний потік ордерів
WebSocket — природний вибір для стаканів у реальному часі, стрімінгу ринкових даних та активного керування ордерами. Стрім може передавати окремі угоди та події стакана, тоді як REST-ендпоінт може надавати лише свічки або періодичні знімки стакана.
Корисне правило: чим більше ваша логіка прийняття рішень залежить від того, що сталося між свічками, тим важливішим є стрімінг. Якщо ваша стратегія оцінює ринок раз на кілька хвилин по закритих свічках, опитування через REST може бути достатнім, а додаткова складність стрімінгу не принесе переваг.
Як ліміти запитів впливають на вибір
Швидкість — не єдина змінна. Біржі обмежують кількість викликів, і ці ліміти відрізняються залежно від протоколу та ендпоінту.
- Деякі біржі встановлюють жорсткі ліміти на публічні REST-ендпоінти (наприклад, 10 запитів на секунду), тоді як повідомлення через WebSocket можуть мати значно вищий ліміт (до 100 на секунду).
- Інші біржі використовують спільні ліміти для REST та WebSocket, щоб захистити ринки від маніпуляцій зі стаканом.
- Обмеження на кількість одночасних підключень з однієї IP-адреси є критичними, якщо ви запускаєте кілька ботів з одного сервера.
Зв'язок тут простий: постійне опитування REST для отримання цін витрачає ваш бюджет запитів на дані, які могли навіть не змінитися. Стрім надсилає зміни автоматично, не витрачаючи ліміти на кожен запит, що залишає ресурси REST для дій, де вони дійсно потрібні.
Де WebSocket дає збій і як з цим працюють професійні боти
Критика WebSockets зазвичай стосується не самого протоколу, а того, як організовано роботу навколо нього. Надійність залежить від керування з'єднанням. З'єднання, яке вважається постійним без постійного моніторингу, є точкою відмови.
Heartbeats та повторна підписка
З'єднання може розірватися непомітно для обох сторін. Системний бот моніторить «серцебиття» (heartbeats), розцінює відсутність сигналу як розрив, перепідключається з експоненціальною затримкою (backoff) та повторно підписується на всі потрібні канали.
Синхронізація стану після перепідключення
Простого перепідключення недостатньо. Під час розриву ордери могли бути виконані, скасовані або відхилені, а локальна копія стакана застаріла. Правильна послідовність дій:
- Виявлення розриву з'єднання.
- Перепідключення та повторна підписка.
- Запит відкритих ордерів та балансів через REST.
- Перебудова локального стакана зі свіжого знімка.
- Тільки після цього — відновлення логіки прийняття рішень.
Це найкращий приклад того, чому ці два протоколи доповнюють один одного: WebSocket забезпечує потік, а REST верифікує стан.
Скасування при розриві (Cancel-on-disconnect)
Якщо сесія переривається, поки ордери знаходяться в стакані, ринок може рухатися, а бот про це не знатиме. Деякі біржі пропонують механізм «dead-man's-switch» (автоматичне скасування при розриві). Якщо такої функції немає, бот повинен мати власний цикл звірки стану ордерів через API після відновлення зв'язку.
Повільні споживачі
WebSockets не мають вбудованого контролю протитиску. Якщо ваш код обробляє повідомлення повільніше, ніж біржа їх надсилає, буфер зростає, поки біржа не розірве з'єднання з помилкою на кшталт «connection too slow». Рішення: тримайте цикл отримання даних легким і асинхронним, передаючи обробку в окремі потоки або процеси.
Чи застарів WebSocket і чи є щось краще?
Ні, WebSocket не застарів. Це зрілий стандарт (RFC 6455). Новіші варіанти, такі як WebTransport, додають керування потоками, але мають обмежену підтримку, і біржі поки що не перевели свої торгові API на них.
FIX — ще одна альтернатива. Він забезпечує детермінований порядок повідомлень і повтор сесій, зазвичай використовується з колокацією для інституційного HFT. Для роздрібних трейдерів REST + WebSocket є практичним «золотим стандартом» і максимальною необхідною потужністю.
Питання безпеки
Для торгових інтеграцій правильний дизайн передбачає, що чутливі операції (автентифікація, великі зміни в обліковому записі) залишаються на стандартних REST-ендпоінтах або спеціальному проксі-шарі, а WebSocket використовується лише для даних та виконання ордерів.
Те саме стосується облікових даних. API-ключ повинен мати лише необхідні дозволи, а права на вивід коштів мають бути вимкнені. Детальніше про це читайте в наших матеріалах про безпеку API-ключів у криптотрейдингу та IP-обмеження для API-ключів.
Фреймворк для прийняття рішення
Ставте ці питання по порядку:
- Як часто стратегія приймає рішення? Раз на свічку або рідше $ ightarrow$ REST може бути достатнім. Постійна реакція на зміни стакана $ ightarrow$ використовуйте WebSocket.
- Чи потрібні дані на рівні окремих подій? Окремі угоди та події стакана зазвичай доступні лише через стріми.
- Наскільки обмежений бюджет запитів? Велика кількість пар або акаунтів робить опитування дорогим. Перевірте ліміти біржі.
- Яка ціна дії на основі застарілих даних? Якщо вона висока, додайте звірку через REST після кожного розриву та за регулярним графіком.
- Чи можете ви самостійно керувати шаром з'єднання? Heartbeats, перепідключення та синхронізація — це серйозна інженерна робота. Якщо ви не хочете цим займатися, використовуйте готову платформу.
| Завдання | Рекомендований канал |
|---|---|
| Живий стакан та угоди | WebSocket |
| Виставлення ордерів (чутливість до затримки) | WebSocket (або REST, якщо час не критичний) |
| Оновлення статусів ордерів | WebSocket, верифікація через REST |
| Баланси та позиції | REST |
| Історичні свічки та історія угод | REST |
| Депозити та виводи | REST |
| Звірка після розриву з'єднання | REST |
Наш погляд
Ми розглядаємо це не як питання переваги протоколу, а як питання дисципліни виконання. Торгова система — це набір правил, які повинні працювати однаково і о 3-й годині ночі, і опівдні. Саме на рівні з'єднання найчастіше втрачається ця стабільність.
Тому ми розглядаємо розподіл протоколів як засіб контролю ризиків. Стрімінг — для спостереження та швидкої реакції. Прямі запити-відповіді — для підтвердження. Бот ніколи не повинен припускати, що його локальна картина правильна після будь-якого переривання: він має перевірити, а потім діяти.
Якщо ви хочете побачити, як інтеграція працює на практиці, наші статті про інтеграцію бірж на основі API та мультибіржову інтеграцію розкривають ці концепції детальніше.
— Гриша
Довірте керування з'єднанням платформі
Якщо ви не бажаєте самостійно розробляти та підтримувати логіку перепідключення, синхронізації та обробки лімітів, Darkbot підключається до підтримуваних бірж через API-ключі та запускає стратегії на основі правил з контролем ризиків, бектестингом і паперовою торгівлою. Ознайомитися з тарифами можна на сторінці ціноутворення. Пам'ятайте: автоматизація забезпечує стабільність виконання, а не напрямок ринку.
FAQ
Навіщо використовувати WebSockets замість REST?
WebSockets надсилають оновлення через відкрите з'єднання, тому ви отримуєте зміни в стакані та статуси ордерів без повторних запитів. Це знижує накладні витрати та економить ваш ліміт запитів.
Які недоліки WebSockets?
Вони мають стан, тому потрібно керувати heartbeats та перепідключенням. Також вони не мають вбудованого контролю протитиску, що може призвести до відключення повільних клієнтів.
Чи застарів WebSocket?
Ні. Це стабільний стандарт RFC 6455, який залишається основним для отримання даних у реальному часі на більшості бірж.
Чи існує щось краще за WebSockets?
Для інституційного HFT з колокацією використовується FIX. Для всіх інших REST + WebSocket є оптимальним та достатнім рішенням.
Чи можна запустити бота тільки на REST?
Так, якщо ваша стратегія працює на повільних таймфреймах і ви вкладаєтеся в ліміти запитів біржі.
Джерела
- Which API should I use? REST versus WebSocket, Kraken Support
- Web socket VS REST API for 5 min Trading frequency, r/algotrading
- WebSocket API Overview, OpenMarket
- WebSocket API, MDN
- Writing WebSocket servers, MDN
- Exchange Rate Limits, Coinbase Developer Platform
- Trading rate limits, Kraken
- API Connection Management Best Practices, Deribit
- Choose your protocol, Kraken Developers
- RFC 6455: The WebSocket Protocol
Рекомендовано
Почніть торгувати із Darkbot з легкістю
Відкрийте для себе нашу платформу для торгівлі криптовалютами, підключивши безкоштовний рахунок!
Безкоштовний план • Без кредитної картки
