API websocket vs rest pour les données en temps réel?
J'ai besoin d'accéder constamment à un serveur pour obtenir des données en temps réel des instruments financiers. Le prix change constamment, je dois donc demander de nouveaux prix toutes les 0,5 secondes. Les API REST des courtiers me permettent de le faire, cependant, j'ai remarqué qu'il y a un certain retard lors de la connexion au serveur. Je viens de remarquer qu'ils ont aussi une API websocket cependant. lire, ils ont tous deux des avantages/inconvénients. Mais pour ce que je veux faire et parce que la vitesse est particulièrement importante ici, quel type si l'API recommanderiez-vous? Le websocket est-il vraiment plus rapide?
Je vous remercie!
L'opération la plus efficace pour ce que vous décrivez serait d'utiliser une connexion webSocket entre le client et le serveur et de demander au serveur d'envoyer des informations de prix mises à jour directement au client via le webSocket UNIQUEMENT lorsque le prix change d'un montant significatif ou lorsqu'un montant minimum du temps s'est écoulé et le prix a changé.
Cela pourrait être beaucoup plus efficace que de demander constamment au client de nouveaux changements de prix et le moment où les nouvelles informations parviennent au client peut être plus rapide.
Donc, si vous êtes intéressé par la rapidité avec laquelle les informations sur un nouveau niveau de prix parviennent au client, un webSocket peut les obtenir beaucoup plus rapidement car le serveur peut simplement envoyer les nouvelles informations de prix directement au client au moment même où elles changent. sur le serveur. Alors qu'en utilisant un appel REST, le client doit interroger sur un intervalle de temps fixe et n'obtiendra jamais de nouvelles données qu'au point de leur intervalle d'interrogation.
Un webSocket peut également être plus rapide et plus facile sur votre infrastructure réseau simplement parce que moins d'opérations réseau sont impliquées pour simplement envoyer un paquet sur une connexion webSocket déjà ouverte par rapport à la création d'une nouvelle connexion pour chaque appel REST/Ajax, l'envoi de nouvelles données, puis la fermeture de la connexion . Quelle différence/amélioration cela fait dans votre application particulière serait quelque chose que vous devriez mesurer pour vraiment savoir.
Mais, les WebSockets ont été conçues pour vous aider avec votre scénario spécifique où un client veut savoir (aussi près du temps réel que possible) quand quelque chose change sur le serveur, donc je pense certainement que ce serait le modèle de conception préféré pour ce type de utilisation.
Voici une comparaison des opérations de mise en réseau impliquées dans l'envoi d'un changement de prix sur un webSocket déjà ouvert par rapport à un appel REST.
webSocket
- Le serveur constate qu'un prix a changé et envoie immédiatement un message à chaque client.
- Le client reçoit le message concernant le nouveau prix.
Repos/Ajax
- Le client configure un intervalle d'interrogation
- Lors du prochain déclenchement d'intervalle d'interrogation, le client crée une connexion socket au serveur
- Le serveur reçoit une demande d'ouverture d'un nouveau socket
- Lorsque la connexion est établie avec le serveur, le client envoie une demande de nouvelles informations de tarification au serveur
- Le serveur reçoit une demande de nouvelles informations de tarification et envoie une réponse avec de nouvelles données (le cas échéant).
- Le client reçoit de nouvelles données de tarification
- Le client ferme le socket
- Le serveur reçoit la fermeture du socket
Comme vous pouvez le voir, il y a beaucoup plus en cours dans l'appel Rest/Ajax d'un point de vue réseau car une nouvelle connexion doit être établie pour chaque nouvel appel alors que le webSocket utilise un appel déjà ouvert. De plus, dans les cas webSocket, le serveur envoie simplement de nouvelles données au client lorsque de nouvelles données sont disponibles - le client n'a pas à les demander régulièrement.
Si les informations de tarification ne changent pas très souvent, le scénario REST/Ajax aura également fréquemment des appels "ne rien faire" lorsque le client demande une mise à jour, mais il n'y a pas de nouvelles données. Le boîtier webSocket n'a jamais ce cas inutile car le serveur envoie simplement de nouvelles données lorsqu'elles sont disponibles.