Les API REST suivent un modèle requête-réponse. Votre client envoie une requête au serveur, le serveur la traite et renvoie une réponse. Si vous souhaitez des données actualisées, vous envoyez une nouvelle requête. Ce modèle de sondage est simple et bien maîtrisé, mais il présente une limitation intrinsèque pour les données de marché : vous ne recevez des mises à jour que lorsque vous les demandez.
Les API WebSocket établissent une connexion persistante et bidirectionnelle entre votre client et le serveur. Une fois la connexion établie, le serveur peut transmettre les données à votre client dès qu'elles sont disponibles, sans attendre de requête. Pour les données de marché, cela signifie que vous recevez les mises à jour de transactions et les modifications du carnet d'ordres au moment où elles se produisent, plutôt que de les découvrir lors de votre prochain sondage.
La différence de latence est significative. Avec un sondage REST à intervalles d'une seconde, vous découvrez les nouvelles informations en moyenne 500 millisecondes après qu'elles se soient produites. Avec un flux WebSocket, vous recevez les mises à jour généralement dans les 10 à 50 millisecondes suivant leur traitement par la plateforme d'échange. Pour une stratégie qui opère sur des intervalles d'une minute, cette différence est négligeable. Pour tout ce qui va plus vite, elle compte.
L'utilisation des ressources raconte une autre histoire. Une approche de sondage REST pour 50 paires de trading à intervalles d'une seconde génère 50 requêtes HTTP par seconde, chacune avec la charge liée à l'établissement de la connexion, aux en-têtes et à l'authentification. Une approche WebSocket utilise 50 connexions persistantes (ou même une seule connexion multiplexée sur certaines plateformes) avec une charge minimale par message. L'approche WebSocket est nettement plus efficace pour la plateforme d'échange et pour votre système.
Les limites de débit favorisent largement l'utilisation des WebSockets. La plupart des plateformes imposent des limites strictes sur les appels d'API REST, généralement de 1 000 à 2 000 requêtes par minute. Si vous surveillez de nombreuses paires de trading, le sondage REST atteint rapidement ces limites. Les flux WebSocket ne sont généralement pas soumis aux mêmes limites de débit, car la plateforme contrôle le flux de données. Vous recevez toutes les mises à jour pour les canaux auxquels vous êtes abonné sans que cela n'affecte votre quota d'API.
C'est avec les données du carnet d'ordres que la différence est la plus marquée. Un appel REST renvoie un instantané du carnet d'ordres au moment de votre requête. Un flux WebSocket vous envoie des mises à jour incrémentales, chaque placement d'ordre individuel, chaque annulation et chaque transaction, vous permettant de maintenir une copie locale synchronisée avec la plateforme d'échange. Ce carnet d'ordres local est essentiel pour les stratégies qui dépendent de l'analyse de profondeur ou de la détection d'ordres importants.
C'est sur le plan de la fiabilité que les connexions WebSocket se compliquent. Les requêtes REST sont sans état. Si l'une d'elles échoue, il suffit de réessayer. Les connexions WebSocket sont avec état. Si la connexion tombe, vous devez vous reconnecter, vous réabonner à vos canaux et éventuellement resynchroniser votre carnet d'ordres local. Les ruptures de connexion surviennent régulièrement, parfois à cause de problèmes réseau, parfois à cause de la maintenance de la plateforme, parfois sans raison apparente. Un code client WebSocket robuste inclut une reconnexion automatique, une gestion des abonnements et une récupération d'état.
La plupart des systèmes de trading professionnels utilisent les deux. Les connexions WebSocket gèrent la diffusion de données en temps réel pour les décisions de trading en direct. Les API REST gèrent les opérations non sensibles au temps, comme la consultation des soldes de compte, l'examen de l'historique des transactions et la gestion des clés d'API. La soumission d'ordres peut se faire dans les deux sens. Certaines plateformes prennent en charge le placement d'ordres via WebSocket pour une latence réduite, tandis que d'autres n'acceptent les ordres qu'à travers les points de terminaison REST.
La recommandation pratique pour construire un système de trading est de commencer par WebSocket pour les données de marché et REST pour la gestion des ordres. Cela vous offre des données en temps réel pour la prise de décision tout en gardant le code de gestion des ordres simple et facile à déboguer. À mesure que votre système évolue et que la latence devient plus importante, vous pouvez migrer la gestion des ordres vers WebSocket si la plateforme le prend en charge. L'essentiel est de concevoir votre système dès le premier jour pour gérer le manque de fiabilité inhérent aux connexions persistantes.