Quels sont les pièges de l'utilisation de Websockets à la place de HTTP RESTful?
Je travaille actuellement sur un projet qui nécessite que le client demande un gros travail et l'envoie au serveur. Ensuite, le serveur divise le travail et répond avec un tableau d'URL pour que le client effectue un appel GET et renvoie les données. Je suis le chef de file du projet et j'utilise actuellement les Websockets Spring pour améliorer l'efficacité. Au lieu que les clients pingent constamment le serveur pour voir s'il a des résultats prêts à être retransmis, le websocket contactera maintenant directement le client hourra!
Serait-ce une mauvaise idée d'avoir des websockets pour gérer l'ensemble du processus de bout en bout? J'utilise STOMP avec des websockets Spring, y aura-t-il encore des problèmes majeurs avec l'abandon de REST?
Avec HTTP RESTful, vous avez un système de demande/réponse sans état où le client envoie la demande et le serveur renvoie la réponse.
Avec webSockets, vous avez un système de transmission de messages avec état (ou potentiellement avec état) où les messages peuvent être envoyés dans un sens ou dans l'autre et l'envoi de tout message donné est plus léger qu'avec une demande/réponse HTTP RESTful.
Les deux sont des structures assez différentes avec des forces différentes.
Les principaux avantages d'un webSocket connecté sont:
Communication bidirectionnelle. Ainsi, le serveur peut à tout moment notifier le client. Ainsi, au lieu d'interroger un serveur à intervalles réguliers pour voir s'il y a quelque chose de nouveau, un client peut établir un webSocket et simplement écouter les messages provenant du serveur. Du point de vue du serveur, lorsqu'un événement intéressant un client se produit, le serveur envoie simplement un message au client. Le serveur ne peut pas le faire avec HTTP simple.
Frais généraux inférieurs par message. Si vous prévoyez un trafic important entre le client et le serveur, il y a des frais généraux inférieurs par message avec un webSocket. En effet, la connexion TCP est déjà établie et vous n'avez qu'à envoyer un message sur une socket déjà ouverte. Avec une requête HTTP REST, vous devez établissez d'abord une connexion TCP qui est plusieurs allers-retours entre le client et le serveur. Ensuite, vous envoyez une requête HTTP, recevez la réponse et fermez la connexion TCP. La demande HTTP inclura nécessairement des frais généraux tels que tous les cookies qui sont alignés avec ce serveur même si ceux-ci ne sont pas pertinents pour la demande particulière. HTTP/2 (dernière spécification HTTP) permet une certaine efficacité supplémentaire à cet égard s'il est utilisé par le client et le serveur, car une seule connexion TCP peut être utilisée pour plus qu'une simple demande/réponse. Si vous avez répertorié toutes les demandes/réponses en cours à TCP niveau juste pour faire une https REST demande/réponse, vous seriez surpris de voir combien il se passe par rapport à simplement envoyer un message sur un webSock déjà établi et.
Échelle plus élevée dans certaines circonstances. Avec une surcharge par message plus faible et sans interrogation de client pour savoir si quelque chose est nouveau, cela peut conduire à une évolutivité accrue (plus grand nombre de clients qu'un serveur donné peut servir). L'évolutivité de webSocket présente également des inconvénients (voir ci-dessous).
Connexions avec état. Sans recourir aux cookies et aux identifiants de session, vous pouvez directement stocker l'état dans votre programme pour une connexion donnée. Alors que beaucoup de développement a été fait avec des connexions sans état pour résoudre la plupart des problèmes, il est parfois plus simple avec des connexions avec état.
Les principaux avantages d'une requête/réponse HTTP RESTful sont:
Support universel. Il est difficile d'obtenir un support plus universel que HTTP. Bien que les webSockets bénéficient maintenant d'un support relativement bon, il existe encore certaines circonstances où le support webSocket n'est pas régulièrement disponible.
Compatible avec plus d'environnements de serveurs. Il existe des environnements de serveurs qui ne permettent pas de longs processus de serveur (certaines situations d'hébergement partagé). Ces environnements peuvent prendre en charge la requête HTTP, mais ne peuvent pas prendre en charge les connexions WebSocket de longue durée.
Échelle plus élevée dans certaines circonstances. L'exigence webSocket pour une socket TCP connectée en continu ajoute de nouvelles exigences d'échelle à l'infrastructure du serveur que les requêtes HTTP n'exigent pas. Donc, cela finit par être un espace de compromis. Si les avantages des webSockets ne sont pas vraiment nécessaires ou utilisés de manière significative, les requêtes HTTP pourraient en fait être mieux adaptées. Cela dépend certainement du profil d'utilisation spécifique.
Pour un one-off demande/réponse, une seule requête HTTP est plus efficace que d'établir un webSocket, de l'utiliser et de le fermer. En effet, l'ouverture d'un webSocket commence par une demande/réponse HTTP, puis après que les deux parties ont convenu de passer à une connexion webSocket, le message webSocket réel peut être envoyé.
Stateless. Si votre travail n'est pas rendu plus compliqué par une infrastructure sans état, un monde sans état peut faciliter la mise à l'échelle (ajoutez simplement plus de processus serveur derrière un équilibreur de charge).
Mise en cache automatique. Avec les bons paramètres du serveur, les réponses http peuvent être mises en cache par le navigateur ou par des mandataires. Il n'existe aucun mécanisme intégré de ce type pour les demandes envoyées via webSockets.
Donc, pour répondre à la façon dont vous avez posé la question:
Quels sont les pièges de l'utilisation de websockets à la place de HTTP RESTful?
À grande échelle (des centaines de milliers de clients), vous devrez peut-être effectuer un travail de serveur spécial afin de prendre en charge un grand nombre de webSockets connectés simultanément.
Tous les clients ou jeux d'outils possibles ne prennent pas en charge les WebSockets ou les demandes effectuées sur eux au même niveau qu'ils prennent en charge les demandes HTTP.
Certains des environnements de serveur les moins chers ne prennent pas en charge les processus serveur de longue durée requis pour prendre en charge les webSockets.
S'il est important pour votre application de renvoyer des notifications de progression au client, vous pouvez soit utiliser une connexion http de longue durée avec une progression continue vers le bas, soit utiliser un WebSocket. Le webSocket est probablement plus facile. Si vous n'avez vraiment besoin du webSocket que pour la durée relativement courte de cette activité particulière, vous pouvez trouver que le meilleur ensemble global de compromis vient en utilisant un webSocket uniquement pour la durée lorsque vous avez besoin de la capacité de pousser des données vers le client et puis en utilisant les requêtes http pour les activités normales de requête/réponse.
Cela dépend vraiment de vos besoins. REST peuvent être beaucoup plus transparents et plus faciles à récupérer par le développeur que les Websockets.
À l'aide de Websockets, vous supprimez la plupart des avantages des services Web RESTful, tels que la possibilité de référencer une ressource via un URI. Vraiment, ce que vous devriez faire, c'est de déterminer quels sont les avantages de REST et hypermédia, et en fonction de cela, décider si ces avantages sont importants pour vous.
Il est bien sûr tout à fait possible de créer un service Web RESTful et de l'étoffer avec une API basée sur Websocket pour des réponses en temps réel.
Mais si vous créez un service que vous seul allez utiliser dans un environnement contrôlé, le seul inconvénient pourrait être que tous les clients ne prennent pas en charge les websockets, alors que pratiquement n'importe quel type d'environnement peut effectuer un simple appel http.