web-dev-qa-db-fra.com

API Websocket pour remplacer REST?

J'ai une application dont la fonction principale fonctionne en temps réel, via des websockets ou de longs sondages.

Cependant, la plupart du site est écrit de manière RESTful, ce qui est agréable pour les applications et autres clients à l'avenir. Cependant, je pense à la transition vers une API websocket pour toutes les fonctions du site, loin de REST. Cela me permettrait d'intégrer plus facilement des fonctionnalités en temps réel dans toutes les parties du site. Cela rendrait-il plus difficile la création d'applications ou de clients mobiles?

J'ai trouvé que certaines personnes font déjà des trucs comme ça: SocketStream

javascriptrestnode.jswebsocket
93
Harry

Pour ne pas dire que les autres réponses ici n'ont pas de mérite, elles soulèvent de bons points. Mais je vais aller à l'encontre du consensus général et je suis d'accord avec vous que le passage aux websockets pour plus que des fonctionnalités en temps réel est très attrayant.

J'envisage sérieusement de déplacer mon application d'une architecture RESTful vers plus d'un style RPC via des websockets. Ce n'est pas une "application jouet", et je ne parle pas uniquement des fonctionnalités en temps réel, j'ai donc des réserves. Mais je vois de nombreux avantages à suivre cette voie et je pense que cela pourrait s'avérer une solution exceptionnelle.

Mon plan consiste à utiliser DNode , SocketIO et Backbone . Avec ces outils, mes modèles et collections Backbone peuvent être transmis de/vers le client et le serveur en appelant simplement une fonction de style RPC. Plus besoin de gérer REST points de terminaison, sérialisation/désérialisation d'objets, etc.) Je n'ai pas encore travaillé avec socketstream, mais cela semble intéressant à vérifier.

J'ai encore beaucoup de chemin à parcourir avant de pouvoir affirmer définitivement que c'est une bonne solution, et je suis sûr que ce n'est pas la meilleure solution pour chaque application, mais je suis convaincu que cette combinaison serait exceptionnellement puissante. J'admets qu'il y a certains inconvénients, comme la perte de la capacité de mettre en cache les ressources. Mais j'ai le sentiment que les avantages l'emporteront sur eux.

Je serais intéressé à suivre vos progrès dans l'exploration de ce type de solution. Si vous avez des expériences avec Github, veuillez me les indiquer. Je n'en ai pas encore, mais j'espère bientôt.

Vous trouverez ci-dessous une liste de liens à lire ultérieurement que j'ai collectés. Je ne peux pas garantir qu'ils valent tous la peine, car je n'en ai parcouru qu'un grand nombre. Mais j'espère que certains vous aideront.

Grand tutoriel sur l'utilisation de Socket.IO avec Express. Il expose des sessions express à socket.io et explique comment avoir des salles différentes pour chaque utilisateur authentifié.

Tutoriel sur node.js/socket.io/backbone.js/express/connect/jade/redis avec authentification, hébergement Joyent, etc:

Tutoriel sur l'utilisation de Pusher avec Backbone.js (à l'aide de Rails):

Créez une application avec backbone.js sur le client et node.js avec express, socket.io, dnode sur le serveur.

Utilisation de Backbone avec DNode:

89
Tauren

HTTP REST et WebSockets sont très différents. HTTP est sans état , donc le serveur Web n'a besoin de rien savoir et vous obtenez la mise en cache dans le navigateur Web et dans les proxys. Si vous utilisez WebSockets, votre serveur devient avec état et vous devez avoir une connexion au client sur le serveur.

Communication demande-réponse vs push

N'utilisez WebSockets que si vous devez pousser les données du serveur vers le client, ce modèle de communication n'est pas inclus dans HTTP ( uniquement par des solutions de contournement). Push est utile si les événements créés par d'autres clients doivent être disponibles pour d'autres clients connectés, par exemple dans les jeux où les utilisateurs doivent agir sur le comportement des autres clients. Ou si votre site Web surveille quelque chose, où le serveur envoie des données au client tout le temps, par exemple marchés boursiers (en direct).

Si vous n'avez pas besoin de pousser les données du serveur, il est généralement plus facile d'utiliser un serveur HTTP sans état REST. HTTP utilise un modèle de communication simple Request-Reply .

52
Jonas

Je pense à la transition vers une API WebSocket pour toutes les fonctions du site

Non, vous ne devriez pas le faire. Il n'y a aucun mal si vous supportez les deux modèles. Utilisez [~ # ~] reste [~ # ~] pour la communication à sens unique/les demandes simples et WebSocket pour une communication bidirectionnelle, en particulier lorsque le serveur souhaite envoyer une notification en temps réel.

WebSocket est un protocole plus efficace que HTTP RESTful mais quand même RESTful HTTP marque sur WebSocket dans les zones ci-dessous.

  1. Les ressources de création/mise à jour/suppression ont été bien définies pour HTTP. Vous devez implémenter ces opérations à bas niveau pour WebSockets.

  2. Les connexions WebSocket évoluent verticalement sur un seul serveur alors que les connexions HTTP évoluent horizontalement. Il existe des solutions propriétaires non basées sur des normes pour la mise à l'échelle horizontale de WebSocket.

  3. HTTP est livré avec beaucoup de bonnes fonctionnalités telles que la mise en cache, le routage, le multiplexage, le gzipping, etc. Celles-ci doivent s'appuyer sur Websocket si vous choisissez Websocket.

  4. Les optimisations des moteurs de recherche fonctionnent bien pour les URL HTTP.

  5. Tous les proxy, DNS, pare-feu ne sont pas encore pleinement conscients du trafic WebSocket. Ils autorisent le port 80 mais peuvent restreindre le trafic en l'espionnant d'abord.

  6. La sécurité avec WebSocket est une approche tout ou rien.

Jetez un œil à ceci article pour plus de détails.

36
Ravindra babu

Le seul problème que je peux utiliser TCP (WebSockets) comme stratégie principale de livraison de contenu Web est qu'il y a très peu de lecture sur la façon de concevoir l'architecture et l'infrastructure de votre site Web à l'aide de TCP.

Vous ne pouvez donc pas apprendre des erreurs des autres et le développement va être plus lent. Ce n'est pas non plus une stratégie "éprouvée".

Bien sûr, vous allez également perdre tous les avantages de HTTP (être sans état et la mise en cache sont les plus grands avantages).

N'oubliez pas que HTTP est une abstraction pour TCP conçu pour servir du contenu Web.

Et n'oublions pas que le référencement et les moteurs de recherche ne font pas de websockets. Vous pouvez donc oublier le référencement.

Personnellement, je recommanderais contre cela car il y a trop de risques.

N'utilisez pas WS pour servir des sites Web, utilisez-le pour servir des applications Web

Cependant, si vous avez un jouet ou un site Web personnel par tous les moyens allez-y. Essayez-le, soyez à la pointe. Pour une entreprise ou une entreprise, vous ne pouvez pas justifier le risque de le faire.

10
Raynos

J'ai appris une petite leçon (à la dure). J'ai créé une application de calcul de nombre qui s'exécute sur les services cloud Ubuntu AWS EC2 (utilise des GPU puissants), et je voulais en faire un front-end juste pour suivre sa progression en temps réel. En raison du fait qu'il avait besoin de données en temps réel, il était évident que j'avais besoin de websockets pour pousser les mises à jour.

Cela a commencé avec une preuve de concept et a très bien fonctionné. Mais ensuite, lorsque nous avons voulu le rendre accessible au public, nous avons dû ajouter une session utilisateur, nous avions donc besoin de fonctionnalités de connexion. Et peu importe comment vous le regardez, le websocket doit savoir avec quel utilisateur il traite, alors nous avons pris le raccourci pour utiliser les websockets pour authentifier les utilisateurs. Cela semblait évident et c'était pratique.

En fait, nous avons dû passer un peu de temps pour rendre les connexions fiables. Nous avons commencé avec des tutoriels Websocket bon marché, mais nous avons découvert que notre implémentation n'était pas en mesure de se reconnecter automatiquement lorsque la connexion était rompue. Tout cela s'est amélioré lorsque nous sommes passés à socket-io. Socket-io est un must!

Cela dit, pour être honnête, je pense que nous avons raté de superbes fonctionnalités socket-io. Socket-io a beaucoup plus à offrir, et je suis sûr, si vous en tenez compte dans votre conception initiale, vous pouvez en tirer le meilleur parti. En revanche, nous venons de remplacer les anciennes websockets par la fonctionnalité websocket de socket-io, et c'était tout. (pas de pièces, pas de chaînes, ...) Une refonte aurait pu rendre tout plus puissant. Mais nous n'avions pas le temps pour ça. C'est quelque chose à retenir pour notre prochain projet.

Ensuite, nous avons commencé pour stocker de plus en plus de données (historique utilisateur, factures, transactions, ...). Nous l'avons stocké dans une base de données AWS dynamodb, et ENCORE, nous avons utilisé socket-io pour communiquer les opérations CRUD du front-end au backend. Je pense que nous avons pris un mauvais virage là-bas. C'était une erreur.

  • Parce que peu de temps après, nous avons découvert que les services cloud d'Amazon (AWS) offrent d'excellents outils d'équilibrage de charge/de mise à l'échelle pour les applications RESTful.
  • Nous avons maintenant l'impression que nous devons écrire beaucoup de code pour effectuer les poignées de main des opérations CRUD.
  • Récemment, nous avons implémenté l'intégration Paypal. Nous avons réussi à le faire fonctionner. Mais encore une fois, tous les tutoriels le font avec les API RESTful. Nous avons dû réécrire/repenser leurs exemples pour les implémenter avec des websockets. Nous l'avons cependant fait fonctionner assez rapidement. Mais on a l'impression que nous sommes allant à contre-courant.

Cela dit, nous allons vivre la semaine prochaine. Nous sommes arrivés à temps, tout fonctionne. Et c'est rapide, mais va-t-il évoluer?

3
bvdb

J'envisagerais d'utiliser les deux . Chaque technologie a son mérite et il n'y a pas de solution universelle.

La séparation du travail se fait de cette façon:

  1. WebSockets serait la méthode principale d'une application pour communiquer avec le serveur lorsqu'une session est requise. Cela élimine de nombreux hacks nécessaires aux anciens navigateurs (le problème est la prise en charge des anciens navigateurs qui éliminera cela)

  2. L'API RESTful est utilisée pour les appels GET qui ne sont pas orientés session (ie pas d'authentification nécessaire) qui bénéficient de la mise en cache du navigateur. Un bon exemple serait les données de référence pour les listes déroulantes utilisées par une application Web. Toutefois. peut changer un peu plus souvent que ...

  3. HTML et Javascript. Ceux-ci comprennent l'interface utilisateur de la webapp. Ceux-ci gagneraient généralement à être placés sur un CDN.

  4. Les services Web utilisant [~ # ~] wsdl [~ # ~] sont toujours le meilleur moyen de niveau entreprise et la communication inter-entreprises car elle fournit une norme bien définie pour le passage des messages et des données. Principalement, vous déchargeriez cela sur un appareil Datapower pour le proxy à votre gestionnaire de services Web.

Tout cela se produit sur le protocole HTTP qui permet déjà d'utiliser des sockets sécurisés via SSL.

Cependant, pour l'application mobile, les websockets ne peuvent pas se reconnecter à une session déconnectée ( Comment se reconnecter à websocket après une connexion étroite ) et la gestion n'est pas anodine. Donc pour les applications mobiles , je recommanderais toujours REST API et sondage.

Une autre chose à surveiller lors de l'utilisation de WebSockets vs REST est l'évolutivité . Les sessions WebSocket sont toujours gérées par le serveur. L'API RESTful, lorsqu'elle est effectuée correctement, est sans état (ce qui signifie qu'il n'y a pas d'état de serveur à gérer), donc l'évolutivité peut croître horizontalement (ce qui est moins cher) que verticalement .

3
Archimedes Trajano

Est-ce que je veux des mises à jour du serveur?

  • Oui: Socket.io
  • Pas de repos

Les inconvénients de Socket.io sont:

  • Évolutivité: les WebSockets nécessitent des connexions ouvertes et une configuration Ops très différente à l'échelle du Web.
  • Learnin: Je n'ai pas de temps illimité pour mon learnin. Il faut faire les choses!

J'utiliserai toujours Socket.io dans mon projet, mais pas pour les formulaires Web de base que REST fera bien.

2
Michael Cole

Les transports basés sur WebSockets (ou longue interrogation) servent principalement à la communication (presque) en temps réel entre le serveur et le client. Bien qu'il existe de nombreux scénarios où ces types de transports sont requis, tels que le chat ou certains types de flux en temps réel ou d'autres choses, toutes les parties d'une application Web ne doivent pas nécessairement être connectées bidirectionnellement avec le serveur.

REST est une architecture basée sur les ressources qui est bien comprise et offre ses propres avantages par rapport aux autres architectures. Les WebSockets s'inclinent davantage vers les flux/flux de données en temps réel, ce qui vous obligerait à créer une sorte de logique basée sur le serveur afin de hiérarchiser ou de différencier les ressources et les flux (au cas où vous ne voudriez pas utiliser REST).

Je suppose qu'à terme, il y aura plus de frameworks centrés WebSockets comme socketstream à l'avenir, lorsque ce transport sera plus répandu et mieux compris/documenté sous la forme de type de données/forme de livraison agnostique. Cependant, je pense que cela ne signifie pas qu'il remplacerait/devrait remplacer le REST simplement parce qu'il offre des fonctionnalités qui ne sont pas nécessairement requises dans de nombreux cas d'utilisation et scénarios.

1
yojimbo87