Наші API надають можливість програмно взаємодіяти з нашими платформами, але обидві платформи пропонують два різні інтерфейси: на Spot — REST та WebSocket (v1 та v2), а на Futures — також API REST та WebSocket. Іноді вибір найбільш відповідного інтерфейсу для конкретного завдання може бути складним рішенням.
На Spot, хоча обидва надають однакові ринкові дані (книги ордерів, історія торгівлі тощо) та однакові дані облікового запису (баланси рахунків, статус ордерів/угод тощо), REST та WebSocket роблять це значно різними способами.
REST пропонує інтерфейс типу «виклик/відповідь» (запитання/відповідь) і надає знімок поточних даних, тоді як WebSocket пропонує інтерфейс типу «жива трансляція» та надає оновлення в реальному часі.
Аналогією може бути різниця між фотографією та відео: за запитом фотографія надає знімок об'єкта, але без подальших оновлень, тоді як відео надає перегляд об'єкта в реальному часі з оновленнями в прямому ефірі.
Хоча ні REST, ні WebSocket не є складними для впровадження, загальноприйнято, що REST менш складний, що дозволяє скоротити час розробки та швидше вирішувати будь-які подальші проблеми.
REST базується на стандартних HTTPS-запитах, які включені до стандартних бібліотек усіх сучасних мов програмування (і можуть бути легко закодовані з нуля, якщо ні), тоді як WebSocket базується на оновленні WSS з HTTPS, що зазвичай вимагає додаткових сторонніх бібліотек (таких як наша рекомендована бібліотека WebSocket для Python).
Наші сторінки підтримки API надають готові до використання приклади коду як для REST, так і для WebSocket, тому вибір інтерфейсу може бути зроблений на основі більш критичних критеріїв, а не простоти впровадження.
Залежно від поставленого завдання, оптимальним вибором буде або лише REST, або лише WebSocket, або, що більш імовірно, комбінація REST та WebSocket.
Для завдань, які вимагають лише періодичних оновлень ринкових даних, REST буде кращим вибором. Наприклад, бот для щоденного усереднення вартості, якому потрібні ринкові дані лише раз на 24 години, не потребуватиме потокових ринкових даних у реальному часі, тому кінцеві точки ринкових даних REST були б більш ніж придатними.
Для завдань, які вимагають найактуальніших ринкових даних, WebSocket буде кращим вибором. Наприклад, арбітражний бот потребуватиме ринкових даних у реальному часі з кількох ринків, щоб скористатися миттєвими розбіжностями в цінах, тому канали ринкових даних WebSocket були б ідеальним вибором.
У більшості випадків (наприклад, для більшості торгових ботів) комбінація REST та WebSocket дозволить досягти найефективнішого впровадження. Наприклад, мобільний додаток може вимагати ринкових даних у реальному часі для своїх графіків, тоді як дані облікового запису потрібні лише час від часу (наприклад, при здійсненні угоди або транзакції фінансування), тому використання каналів ринкових даних WebSocket разом з кінцевими точками статусу ордерів/угод/фінансування REST було б найефективнішою комбінацією.
Наша команда підтримки API буде рада обговорити з вами вашу реалізацію API та надати пропозиції щодо оптимального способу використання нашого API на основі вашого передбачуваного сценарію використання.