Nos API offrent un moyen d'interagir par programmation avec nos plateformes, mais les deux plateformes proposent deux interfaces différentes : sur Spot, REST et WebSocket (v1 et v2), et sur Futures, les API REST et WebSocket sont également fournies. Parfois, choisir l'interface la plus appropriée pour une tâche spécifique peut être une décision difficile.
Sur Spot, bien que les deux fournissent exactement les mêmes données de marché (carnets d'ordres, historique de trading, etc.) et exactement les mêmes données de compte (soldes de compte, statut des ordres/transactions, etc.), REST et WebSocket le font de manières significativement différentes.
REST offre une interface de type appel/réponse (question/réponse) et fournit un instantané des données actuelles, tandis que WebSocket offre une interface de type streaming en direct et fournit des mises à jour en temps réel.
Une analogie serait la différence entre une photographie et une vidéo : sur demande, une photographie fournit un instantané du sujet mais aucune mise à jour supplémentaire, tandis qu'une vidéo fournit une vue en temps réel du sujet avec des mises à jour en direct.
Bien que ni REST ni WebSocket ne soient difficiles à implémenter, il est généralement admis que REST est moins complexe, ce qui permet de réduire le temps de développement et de résoudre plus rapidement les problèmes ultérieurs.
REST est basé sur des requêtes HTTPS standard qui sont incluses dans les bibliothèques standard de tous les langages de programmation modernes (et pourraient facilement être codées à partir de zéro si ce n'était pas le cas), tandis que WebSocket est basé sur une mise à niveau WSS à partir de HTTPS qui nécessite généralement des bibliothèques tierces supplémentaires (telles que notre bibliothèque WebSocket recommandée pour Python).
Nos pages de support API fournissent du code d'exemple prêt à l'emploi pour REST et WebSocket, le choix de l'interface peut donc être fait en utilisant des critères plus critiques plutôt que la facilité d'implémentation.
Selon la tâche à accomplir, soit REST uniquement, soit WebSocket uniquement, soit plus probablement une combinaison des deux (REST et WebSocket) serait le choix optimal.
Pour les tâches qui ne nécessitent que des mises à jour occasionnelles des données de marché, REST serait le choix préféré. Par exemple, un bot de coût moyen quotidien qui ne nécessiterait des données de marché qu'une fois toutes les 24 heures n'aurait pas besoin de données de marché en streaming en temps réel, les points de terminaison de données de marché REST seraient donc plus que suffisants.
Pour les tâches qui nécessitent les données de marché les plus récentes disponibles, WebSocket serait le choix préféré. Par exemple, un bot d'arbitrage aurait besoin de données de marché en temps réel provenant de plusieurs marchés afin de profiter des écarts de prix momentanés, les flux de données de marché WebSocket seraient donc le choix idéal.
Dans la plupart des cas (comme la majorité des bots de trading), une combinaison de REST et WebSocket permettrait l'implémentation la plus efficace. Par exemple, une application mobile pourrait nécessiter des données de marché en temps réel pour ses graphiques, tout en n'ayant besoin de données de compte qu'occasionnellement (lors d'une transaction ou d'une opération de financement, par exemple), l'utilisation des flux de données de marché WebSocket conjointement avec les points de terminaison de statut d'ordre/transaction/financement REST serait donc la combinaison la plus efficace.
Notre équipe de support API serait ravie de discuter de votre implémentation API avec vous et de vous faire des suggestions sur la meilleure façon d'utiliser notre API en fonction de votre scénario d'utilisation prévu.