BT
x Votre opinion compte ! Merci de bien vouloir répondre au sondage InfoQ concernant vos habitudes de lecture !

REST a-t-il besoin de remplaçants ?

par Mark Little , traduit par Hadrien Pierart le 02 janv. 2014 |

Ole Lensmar, le créateur de SoapUI, s'est récemment demandé si REST ne perdait pas son charme et s'il n'y aurait pas besoin de lui trouver des alternatives ? Selon lui :

Ces dernières années, l'adoption de REST comme méthode prédominante de construction d'APIs publiques a éclipsé l'émergence d'autres API ou approches. Bien que certaines alternatives (principalement SOAP) sont toujours (très) présentes en entreprise, les premiers utilisateurs de l'API ont opté pour une position ferme contre celles-ci et ont choisi REST accompagné de JSON comme format de message principal.

Il expose pourquoi, selon lui, REST a eu plus de succès que ses concurrents comme SOAP et XML-RPC. Malgré tout, Ole pense qu'il y a un certain nombre de cas où REST n'est pas adapté et où des alternatives seraient les bienvenues. On trouve entre autres :

  • Les API Asynchrones : "Devoir pousser de la donnée de manière asynchrone au lieu du mode traditionnel requête/réponse ne convient pas toujours très bien pour une application designée avec une API REST. De plus, les technologies sous-jacentes (WebSockets, MQTT, AMQP, Stomp, pubsubhubbub/WebHooks – pour n'en nommer que quelques-unes) sont souvent très différentes de HTTP et ne s'accordent pas correctement avec les principes de REST."
  • Les API d'Orchestration : "Le niveau de granularité offert par les API REST traditionnelles n'est pas toujours un avantage. Récupérer les ressources nécessaires pour un dashboard mobile ou une application single-page complexe peut nécessiter de nombreux appels à l'API. Ce qui ajoute une latence pour la logique côté client, charge la bande passante et nécessite des traitements côté serveur."
  • SDK ou API : "La plupart des utilisateurs d'API consomment ces flux via des langages haut niveau : JavaScript, Python, Ruby, Java, etc. Ce qui a incité beaucoup de fournisseurs d'API à proposer des bibliothèques clients préconstruites pour ces langages (Google, Facebook, etc.). Étant donné que ces langages sont eux-mêmes souvent plus orientés RPC, c'est aussi le cas du code disponible dans les SDK, incitant par la même occasion à l'utilisation de code similaire pour l'API backend. Peut-être qu'en utilisant des protocoles binaires plus optimisés ou en optant pour une utilisation d'HTTP plus proche de RPC (ex : JSON-RPC), cela pourrait être amélioré."
  • Les protocoles binaires : "[...] optimisés pour le transfert de messages par exemple, qui sont un prérequis pour le matériel IoT ou les SDK ; plusieurs d'entre eux reçoivent d'ailleurs pas mal d'attention et d'utilisation" comme Apache Thrift, Google Protocol Buffers, Apache Avro. "[Il est important de noter] que plusieurs des API asynchrones citées précédemment utilisent un format binaire lié à la bande passante et aux restrictions de traitement imposées par le matériel et les services."

Ole prend l'exemple d'Evernote qui utilise Thrift comme protocole sous-jacent par nécessité de faire du temps-réel (ce qui semble également être au-delà des capacités de REST selon Ole). Selon lui, lorsqu'il parle d'un autre article de Daniel Jacobson sur le choix de design sans REST d'Evernote :

[...] Les API REST sont peut-être intéressantes lorsque vous ciblez un grand nombre de développeurs inconnus. Mais si vos API s'adressent à des utilisateurs, marchés, industries ou technologies particulières, choisir une alternative plus spécifique n'est pas délirant – cela peut même mener à des avantages inattendus sur la concurrence en termes de performances, de facilité d'utilisation et de sécurité.

Ole conclut en admettant que la taille unique ne peut pas, par définition, convenir à tout le monde, d'autant plus lorsqu'il s'agit de design d'API. "Heureusement pour nous autres passionnés de technologies, qui construisons et apprenons constamment de nouvelles technologies et les mettons à l'épreuve du mieux que possible est ce qui fait fonctionner le système. Je ne suis donc pas opposé à la diversité, au contraire, elle est la bienvenue."

Pour autant, bien que plusieurs personnes soutiennent Ole dans les commentaires, beaucoup ne sont pas d'accord. Par exemple, selon John Sheehan :

Je ne crois pas qu'Evernote ait abandonné REST ; ils ne l'ont jamais utilisé et ils avaient de bonnes raisons pour cela. Par ailleurs, webhooks peut facilement ressembler REST (du moins au sens populaire du terme). Les limitations suggérées dans la partie Asynchrone ne s'appliquent pas dans les cas d'utilisation les plus courants.

Darrel Miller essaye lui de faire la distinction entre REST et "pop REST" (selon ses termes) :

Compte tenu de ce que je peux voir de la description d'une couche d'orchestration selon Daniel Jacobson, cela est très proche de ma façon de construire des API REST (et hypermédia) depuis pas mal d'années. Ce n'est pas parce que les gens commencent à voir au-delà de la vague “pop REST” que cela remet en question les propriétés de REST définies par Fielding.

Il semble que beaucoup de commentaires insistent sur le fait que Ole n'a pas fait la différence entre les principes mêmes de REST et les implémentations se décrivant comme du REST mais qui ne le sont pas vraiment. Qu'en pensez-vous ? REST est-il applicable dans les différents cas cités par Ole ? Et sinon, quelles alternatives proposeriez-vous ?

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