BT

WebSockets ou REST?

par Mark Little , traduit par Eric Bellemon le 21 mai 2013 |

Ces dernières années, WebSockets a gagné en popularité et en disponibilité. À la fin de l'année dernière, il a franchi une nouvelle étape vers un futur standard en obtenant le statut de W3C Candidate Recommendation. Oracle et d'autres ont aussi récemment soumis une demande pour commencer un effort de standardisation autour des WebSockets (JSR 356) pour la prochaine version de Java Enterprise Edition. Tous les principaux navigateurs, comme Chrome, Firefox, Safari ou IE supportent une version des WebSockets et supporteront quoi qu'il advienne le futur standard. En un laps de temps relativement court, WebSockets est devenu partie intégrante du Web. Mais certains développeurs sont encore incertains sur la façon ou si les WebSockets s'inscrivent dans l'architecture du Web "traditionnel": REST. Certains comme Nathan Evans en viennent même à suggérer que WebSockets pourrait éclipser REST:

Après avoir lu en détail le standard et les différentes discussions sur ce sujet, il m'est devenu extrêmement clair que le standard est parti pour voler une importante part de notoriété aux web services RESTful. Ce que je veux dire c'est qu'il va arriver une étape dans le développement du produit où quelqu'un va poser la question

"Ok les mecs, on utilise les WebSockets ou REST pour ce projet ?"

Je m'attends à ce que les WebSockets commencent, d'ici un ou deux ans, à ralentir la croissance des web services RESTful, du moins celle que l'on connait aujourd'hui.

Dans cet article, Nathan, sur la base de sa propre expérience de REST, estime que ce n'est pas la solution miracle que certains veulent faire croire, même s'il admet que les WebSockets ne sont pas parfaits. Il souligne ensuite plusieurs raisons pour lesquelles les WebSockets sont une menace pour REST. Certains des avantages des WebSockets sur REST sont dus à la communication bidirectionnelle:

La véritable capacité bidirectionnelle offerte par les WebSockets est une première pour un protocole basé sur HTTP. Ni SOAP ou REST ne l'ont et Comet/push/long-polling ne peuvent l’émuler de manière efficace. La capacité bidirectionnelle est intrinsèquement tellement bonne que vous pouvez en faire un tunnel avec un protocole TCP temps réel tel que Remote Desktop ou VNC si vous le voulez.

Nathan croit que les bénéfices des WebSockets vont surpasser ceux de REST (HTTP) et que les développeurs vont migrer vers WebSockets.

REST va certainement rester un choix par défaut pour les projets qui nécessitent une forte visibilité et une compatibilité multiplateforme. Les projets ne nécessitant pas ces exigences vont probablement choisir les WebSockets et encapsuler du JSON dedans ou utiliser un protocole maison. […] Même s'ils sont concurrents, la bonne nouvelle est que REST et WebSockets peuvent actuellement coexister. En fait, parce qu'ils sont tous les deux construits sur HTTP, ils sont complémentaires.

Cependant, Nathan n'est pas le seul à se poser la question "WebSockets vs REST". Par exemple, Shay Bannon se demande en 2010 si c'est possible d'utiliser les principes de REST avec les WebSockets:

D'abord et avant tout, comment représenter une URI ? Deuxièmement, comment représenter les méthodes HTTP (GET, PUT, POST, …) ? Et dernièrement, comment représenter les paramètres et les en-têtes ? Il semble qu'une des solutions soit de construire une sorte de schéma dans le contenu sous forme de texte. Quelque chose comme du JSON qui possède un champ "URI", des champs "params", etc. Mais c'est assez ennuyant, surtout que depuis HTTP, on peut facilement créer des passerelles utilisant les en-têtes et les paramètres sans avoir à parser le contenu...

Il se demande pourquoi les WebSockets n'ont pas de notions d'URI ou d'en-têtes et par conséquent s'il n'y a pas un besoin pour une spécification REST-over-WebSockets avant que les gens ne réinventent REST et finissent par le faire "de manière non uniforme". Il a reçu des réponses mitigées sur son article. Par exemple, un commentaire d'un employé d'une entreprise qui travaille dans le domaine des WebSockets, donc peut-être pas objectif, commence par:

REST et le protocole WebSocket semblent être deux solutions différentes de "plomberie" pour l'informatique distribuée. REST est la version old-school, basé sur HTTP, synchrone à la manière de RPC. WebSocket est le petit nouveau, côtoyant HTTP, utilisé de manière asynchrone. À mon avis, sur le long terme, WebSocket va drastiquement réduire le besoin en REST. Avec WebSocket, tous les protocoles que l'on connait et que nous aimons depuis les dernières décennies peuvent être maintenant étendus sur le web sans les problèmes de performances pour les adapter à HTTP.

Et un autre:

Mon point de vue est que REST implique le paradigme requête/réponse. Au contraire, les sockets sont utiles pour la programmation Comet où les communications restent ouvertes pour plusieurs cycles d'échanges. Aussi la connexion initiale en WS se passe toujours en HTTP, donc en réalité ils ne sont pas incompatibles. J'ai aussi trouvé que le but du protocole WS était de se débarrasser des en-têtes HTTP, car elles devenaient redondantes et ajoutaient juste du poids au contenu.

Cependant même en admettant que REST et WebSockets puissent et doivent coexister, quelques commentaires sont en désaccord avec l'idée d'une spécification de REST-over-WebSockets, quelqu'un ajoutant:

Si vous considérez REST selon la définition de Fielding, avec un internet d'objets adressables (ou de ressources), il ne fonctionne pas dans un format de communication en duplex. On ne s'attend pas à ce que les ressources initient la conversation. Les WebSockets vont transformer le web (s'ils décollent), mais pas comme un protocole de communication de style REST.

Et un dernier donnant un point de vue plus détaillé:

Les WebSockets sont full duplex, ce qui signifie que les deux interlocuteurs peuvent parler en même temps, et les deux parties doivent continuer à écouter pendant qu'elles sont en train de parler. REST est sans état, synchrone et ne traite que les requêtes->réponses. On doit élargir le concept de REST pour obtenir le bénéfice d'une communication client/serveur. J'imagine les avantages d'une librairie implémentant REST en WebSockets mais cela ne serait utile que pour les applications qui ont déjà une API RESTful et voudraient bénéficier des réductions de ressources qu'une connexion unique offre sans avoir à réécrire leur code.

Et il y en a certains dans la communauté REST comme Jim Webber qui croit que les WebSockets ne sont pas adaptés pour le web:

Avec les Websockets pratiquement sur le point de devenir un standard, tout en étant supporté et utilisé dans les navigateurs web, mobile et dans le cloud, il est intéressant de se demander l'importance de l'impact qu'ils vont avoir sur les développeurs qui utilisent actuellement REST et HTTP ou est-ce qu'ils s'adressent à une autre segment de développeurs ? Pire encore, sommes-nous en train comme certains le croient de "briser le web" ?

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT