Quels sont les défauts de REST ?

Il y a quelques années Ganesh Prasad a demandé "Est-ce qu'Internet est plus fondamental que REST ?" Dans les années qui suivirent, il continua d'entretenir la discussion autour de REST, du SOA et plus récemment du Cloud, en mettant en avant les principes directeurs de REST. Cependant, récemment, sur le groupe de discussion LinkedIn des architectes REST quelqu'un a posé la question suivante : "Quels sont les défauts de REST ?" Ganesh écrivit une réponse, qu'il répéta sur son blog :

Je ne dirais pas que REST a des "défauts" en tant que tels. Il fait ce pour quoi il est fait, et le fait très bien. Il ne faut pas oublier que la seule mise en oeuvre de l'approche REST est basée sur le protocole HTTP. Nous pouvons certainement envisager une future mise en oeuvre "REST-ienne" basée sur un autre protocole de transport, et apporter ainsi plusieurs améliorations.

Il poursuivit son explication sur quatre zones d'amélioration possibles. Il est à noter que, comme pour beaucoup de gens, Ganesh fait le raccourci REST pour REST/HTTP c'est à dire REST basé sur HTTP.

1. "HTTP est un protocole synchrone basé sur le principe question/réponse. Cela signifie qu'il ne supporte pas intrinsèquement les appels réciproques (peer-to-peer) initiés par le serveur, alors qu'ils sont souvent nécessaires. C'est pourquoi les fonctions de rappel dans une application de type REST nécesite l'utilisation de modèles applicatifs comme les Webhooks. Maintenant que nous disposons d'un protocole de transport bidirectionnel sous la forme des WebSockets, peut être que l'industrie devrait se pencher sur un nouveau protocole applicatif basé sur ce dernier et reprenant les principes REST." Cela est d'autant plus intéressant qu'au cours de l'année passée, nous avons pu observer des discussions sur la compatibilité même des WebSockets et de REST.
2. Ganesh estime qu'il y a au moins une chose que la communauté REST pourrait apprendre des Services Web WS-* : "Ce sont tous des protocoles de bout-en-bout au dessus du noyau SOAP + WS-Addressing et des capacités d'échange de message (messaging)" D'autres avaient d'ailleurs suggéré des choses similaires par le passé. Ganesh poursuit sur l'analogie entre la façon dont les Services Web utilisent WS-Policy, WS-ReliableMessaging, WS-SecureConversation et WS-Policy, et les équivalents internet tel que TCP, IP et IPSec. Ganesh suggère que l'idempotence d'une application REST est peut-être plus fiable (bien que cette notion de "plus" ne soit définie dans aucun contexte), et qu'il existe probablement des alternatives aux transactions pour l'approche REST, mais il poursuit sur :

Mais ce qu'il reste, c'est la sécurité. WS-SecureConversation avec WS-Security est routable, contrairement à SSL/TLS qui est le seul mécanisme de sécurité dont dispose l'approche REST. Avec WS-Sec*, les messages peuvent aussi être partiellement cryptés, en laissant suffisament de contenu en clair pour faciliter le routage et la distribution. C'est une chose pour laquelle l'approche REST n'a pas d'équivalent élégant. Les connexions sécurisées (SSL) fonctionnent de point-à-point, ne peuvent être inspectées par des intermédiaires (proxies) et violent les principes de l'approche REST. Elles sont uniquement tolérées.

C'est intéressant parce que d'autres, comme Resteasy de Bill Burke, ont suggéré que l'approche REST a besoin d'une meilleure approche de la sécurité. Mais Ganesh continue d'expliquer l'approche REST et plus généralement la Qualité de Service (QoS) :

La raison de l'incapacité de l'approche REST à gérer une telle QoS de manière générale est que tout cela nécessite qu'un "état conservationnel" soit maintenu. L'absence de gestion d'état (Statefulness) a des inconvénients connus (comme les impacts sur l'évolutivité ou la reprise en cas d'erreur) mais avec l'avènement des bases de données NoSQL comme Redis qui prétendent à des temps d'accès constants c'est à dire O(1), il devient possible de déléguer cet état conversationel à ces espaces de stockage et ainsi de partager les sessions à travers plusieurs noeuds uniquement pour permettre de garantir la QoS¹.

Mais revenons sur les deux derniers points exprimés par Ganesh :

1. Il pense que le protocole HTTP a trop peu de verbes, surtout si vous voulez faire des interactions pair-à-pair (peer-to-peer), et fait quelques suggestions : "INCLUDE (ajouter² une ressource à une collection et retourne une URI construite par le serveur), PLACE (ajouter une ressource à une collection sur une URI spécifiée par le client, REPLACE (remplacer³ dans sa totalité), FORCE (PLACE ou REPLACE), AMEND (mise à jour partielle, un verbe conteneur indiquant un ou plusieurs autres verbes indiquant les opérations sur un sous-ensemble de ressources), MERGE (alimenter certaines parties d'une ressource avec la représentation fournie), RETIRE (un terme plus adapté que DELETE) et SOLICIT (un remplacement de GET qui est aussi un verbe conteneur, permettant d'indiquer à son homologue quoi faire avec la/les ressource(s) de l'initiateur, car il s'agit désormais d'un monde pair-à-pair⁴). Il faut penser à GET comme un SOLICIT-POST pour comprendre ce modèle de réciprocité⁵".
2. "HTTP combine les codes d'état applicatifs et liés au transport (par exemple 304 Non Modifié et 400 Requête Invalide vs 407 Authentification Proxy Requise et 502 Passerelle Invalide). La prochaine mise en oeuvre de REST sur un autre transport devrait impliquer une séparation nette entre les protocoles applicatifs et ceux liés aux transports. HTTP a une double fonction et les conséquences sont souvent peu élégantes."

En regardant l'ébauche initiale du protocole HTTP 2.0, il semble qu'il n'adresse pas toutes les suggestions de Ganesh. Cependant, il semblerait que Ganesh lui-même ait travaillé pendant les cinq dernières années sur une proposition de spécification :

Je suis en train d'écrire un document de travail Internet ("Internet Draft"⁶) sur un nouveau protocole applicatif qui pourrait s'appliquer à n'importe quel transport (Pub/Sub, communication Point-à-Point asynchrone ou l'appel synchrone Requête/Réponse). Ce protocole s'inscrit dans le cadre d'une nouvelle architecture de calcul distribué que j'appelle ROMA (Resource/Representation-Oriented Messaging Architecture - Architecture par message orientée Ressource/Representation) et couvre non seulement le modèle de données et les API de message, mais aussi des aspects plus haut niveau (QoS, description et coordination des processus).

Une fois que ce document sera publié, il sera intéressant de voir de quelles façons il aborde les problèmes qui ont été soulevés et s'il reçoit un accueil positif de la communauté REST.

ndt : tirées en partie de What Are The Drawbacks Of REST?

• ¹ L'approche REST préconise une absence d'état chez le fournisseur de ressources (généralement le serveur) il est donc nécessaire pour le demandeur (client) de maintenir cet état conversationnel
• ² comme POST
• ³ similaire à PUT
• ⁴ la notion de pair-à-pair indique essentiellement qu'il n'y a plus de relation client/serveur mais que les deux parties prenantes peuvent interagir l'une avec l'autre de la même façon - voir la note 5.
• ⁵ cette partie n'était pas présente dans l'article original de Mark Little mais apparait dans le Blog de Ganesh, elle me parait importante car elle illustre bien la notion de réciprocité entre les deux parties prenantes ainsi que cette notion de verbe conteneur. La demande de récupération d'un côté peut se traduire par "je te sollicite pour que tu me POST la ressource à cette URI".
• ⁶ il s'agit des documents de travail de l'IETF conduisant généralement aux RFC