Websocket API pour remplacer l'API REST?

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

Cependant, la majeure partie du site est écrite de manière REST, ce qui est bien 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 faciliterait l'intégration 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 faisaient déjà des trucs comme ça: SocketStream

Pour ne pas dire que les autres réponses ici n'ont pas de mérite, elles font valoir quelques bons points. Mais je vais aller à l'encontre du consensus général et convenir 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 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, donc j'ai 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 est d'utiliser DNode , SocketIO et Backbone . Avec ces outils, mes modèles et collections Backbone peuvent être transmis depuis / vers le client et le serveur en appelant simplement une fonction de style RPC. Fini la gestion des points de terminaison REST, la sérialisation / désérialisation d'objets, etc. Je n'ai pas encore travaillé avec socketstream, mais cela vaut la peine d'être vérifié.

J'ai encore un long 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, tels que 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é de suivre vos progrès dans l'exploration de ce type de solution. Si vous avez des expériences 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 plus tard que j'ai collectés. Je ne peux pas garantir qu'ils en valent tous la peine, car je n'en ai parcouru qu'un grand nombre. Mais j'espère que certains aideront.

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

• http://www.danielbaulig.de/socket-ioexpress/

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

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Tutoriel sur l'utilisation de Pusher avec Backbone.js (en utilisant Rails):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

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

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Utilisation de Backbone avec DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST et WebSockets sont très différents. HTTP est sans état , donc le serveur Web n'a pas besoin de savoir quoi que ce soit, 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

Utilisez WebSockets uniquement si vous devez PUSH des 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 d'autres clients. Ou si votre site Web surveille quelque chose, où le serveur envoie les données au client tout le temps, par exemple les marchés boursiers (en direct).

Si vous n'avez pas besoin de PUSH des données du serveur, il est généralement plus facile d'utiliser un serveur HTTP REST sans état. HTTP utilise un modèle de communication simple demande-réponse .

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 prenez en charge les deux modèles. Utilisez REST pour une communication unidirectionnelle / des 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 RESTful HTTP mais toujours RESTful HTTP scores 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 au bas niveau pour les 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 WebSocket.

3. HTTP est livré avec de nombreuses fonctionnalités intéressantes telles que la mise en cache, le routage, le multiplexage, le gzipping, etc. Celles-ci doivent être intégrées au-dessus de Websocket si vous avez choisi 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 le surveillant d'abord.

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

Consultez cet article pour plus de détails.

Le seul problème que je peux utiliser TCP (WebSockets) comme stratégie principale de diffusion de contenu Web est qu'il y a très peu de matériel 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çue 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 déconseillerais 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, allez-y. Essayez-le, soyez à la fine pointe. Pour une entreprise ou une entreprise, vous ne pouvez pas justifier le risque de faire cela.

J'ai appris une petite leçon (à la dure). J'ai créé une application de calcul du nombre qui fonctionne sur les services cloud Ubuntu AWS EC2 (utilise des GPU puissants), et je voulais créer une interface pour elle juste pour regarder ses progrès 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é par une preuve de concept et a très bien fonctionné. Mais ensuite, lorsque nous voulions le rendre accessible au public, nous devions 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, nous avons donc pris le raccourci d'utilisation des websockets pour authentifier les utilisateurs . Cela semblait évident et c'était pratique.

Nous avons en fait dû passer un peu de temps au calme pour fiabiliser les connexions. Nous avons commencé avec des didacticiels Websocket bon marché, mais nous avons découvert que notre implémentation ne pouvait pas se reconnecter automatiquement lorsque la connexion était interrompue. 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 manqué certaines fonctionnalités de socket-io. Socket-io a beaucoup plus à offrir, et je suis sûr que si vous en tenez compte dans votre conception initiale, vous pouvez en tirer davantage. En revanche, nous venons de remplacer les anciens websockets par la fonctionnalité websocket de socket-io, et c'est tout. (pas de salles, pas de canaux, ...) Une refonte aurait pu rendre tout plus puissant. Mais nous n'avons pas eu le temps pour ça. C'est quelque chose à retenir pour notre prochain projet.

Ensuite, nous avons commencé à stocker de plus en plus de données (historique des utilisateurs, factures, transactions, ...). Nous avons tout 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. 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 et de mise à l'échelle pour les applications RESTful .
• On a maintenant l'impression qu'il faut écrire beaucoup de code pour effectuer les handshakes 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 des API RESTful . Nous avons dû réécrire / repenser leurs exemples pour les implémenter avec des websockets. Nous l'avons fait fonctionner assez rapidement. Mais c'est comme si nous allions à 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?

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

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

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

2. L'API RESTful est utilisée pour les appels GET qui ne sont pas orientés session (c.-à-d. Pas d'authentification nécessaire) qui bénéficient de la mise en cache du navigateur. Un bon exemple de ceci 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 l'application Web. Ceux-ci bénéficieraient généralement d'être placés sur un CDN.

4. Les services Web utilisant WSDL restent le meilleur moyen de communication au niveau de l' entreprise et entre les entreprises, car ils fournissent une norme bien définie pour le passage des messages et des données. Vous devez principalement le décharger sur un périphérique Datapower pour le proxy de votre gestionnaire de service 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 fermée ) et gérer cela n'est pas trivial. Donc, pour les applications mobiles , je recommanderais toujours l' API REST et le sondage.

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

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 de l'échelle Web.
• Learnin: Je n'ai pas de temps illimité pour mon apprentissage. Les choses doivent être faites!

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

Les transports basés sur les WebSockets (ou longue interrogation) servent principalement à la communication en temps (quasi) réel entre le serveur et le client. Bien qu'il existe de nombreux scénarios dans lesquels ces types de transports sont nécessaires, tels que le chat ou certains types de flux en temps réel ou d'autres éléments, toutes les parties d'une application Web n'ont pas besoin d'être nécessairement connectées de manière bidirectionnelle 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 ont davantage tendance à utiliser des 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 aurait plus de frameworks centrés sur WebSockets comme socketstream à l'avenir lorsque ce transport serait plus répandu et mieux compris / documenté sous la forme d'une livraison indépendante du type / forme de données. 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.

Je voudrais souligner ce billet de blog qui dépend de moi, la meilleure réponse à cette question.

Bref, OUI

Le message contient toutes les meilleures pratiques pour ce type d'API.

Ce n'est pas une bonne idée. La norme n'est même pas encore finalisée, la prise en charge varie selon les navigateurs, etc. Si vous voulez faire cela maintenant, vous aurez besoin de revenir au flash ou à une longue interrogation, etc. À l'avenir, cela ne fera probablement toujours pas de beaucoup de sens, car le serveur doit prendre en charge le fait de laisser les connexions ouvertes à chaque utilisateur. La plupart des serveurs Web sont plutôt conçus pour exceller à répondre rapidement aux demandes et à les fermer aussi rapidement que possible. Heck, même votre système d'exploitation devrait être réglé pour gérer un nombre élevé de connexions simultanées (chaque connexion utilisant plus de ports et de mémoire éphémères). Tenez-vous-en à utiliser REST pour la plus grande partie possible du site.