Quelques idées reçues sur REST

Les erreurs passent, il n'y a que le vrai qui reste.

Discutons les préjugés qui éclosent autour de REST (REpresentational State Transfer).REST est un style d'architecture fondé sur ce qui définit le WEB.

1. REST n'a rien inventé, le premier des serveurs WEB faisait déjà du REST...

C'est vrai et REST propose une vision d'un WEB étendu aux échanges de machine à machine (M2M) là où le WEB est aujourd'hui un système dont les consommateurs sont des humains.

2. J'ai implémenté un programme sur mon serveur WEB qui renvoie des Représentations différentes en fonction de l'attribut Accept de l'entête HTTP et de la méthode (GET, PUT, DELETE) envoyée par le client, je fais donc du REST.

Partiellement vrai. On ne peut pas vraiment décréter que l'on fait du REST sans savoir à quelles contraintes on doit se plier. Au départ, on trouve la thèse de Roy Fiedling. Il a analysé les caractéristiques du système WEB en interaction avec les utilisateurs humains. Par extension, il a construit le style REST pour le dialogue de machine à machine, dont chacune des propriétés suivantes offrent des qualités au système:

1. Données structurées au dessus d'HTTP: accessibilité
2. Universal Ressource Identifier (URI): adressabilité, diffusabilité de l'information
3. Sans état: montée en charge (scalability)
4. Contrat uniforme (verbes HTTP): inter-médiation (cache, sécurité, etc.), contrôle
5. Sûreté (répétabilité du GET) & idem potence (une modification produit toujours le même résultat, par exemple, la fonction incrément n'est **pas** idempotente): robustesse à la perte de communication serveur
6. Hyperliens (les liens inclus dans la représentation de la ressource permettent de naviger vers ses services associés - pensons aux pages WEB des humains !) : couplage lâche (pas besoin d'extraire l'identification de la ressource pour la passer aux autres services)
7. HATEOAS (Hypermedia As The Engine Of Application State): montée en charge
8. Ressource auto-porteuse de l'information (pas besoin de notice pour consommer la ressource: utiliser le type de la ressource - est-il connu ?, lire son contenu pour trouver comment s'en servir - contient-il des hyperliens ?): couplage lâche

La vision puriste de REST, celle de son créateur, détermine que toutes ces contraintes doivent être respectées pour arriver à un système REST. Dans les faits, seules les premières étapes son outillées. Soyez indulgent avec le prochain puriste qui vous dira que votre système n'est pas REST et demandez lui s'il a bientôt terminé son implémentation pour le support des deux derniers niveaux...Notons qu'aujourd'hui, le WEB "humain" (celui qui nous fait surfer d'une page à l'autre) satisfait ces contraintes, même la dernière: les liens et formulaires des pages sont interprétables par nos cerveaux évolués.

3. Si je dois assurer l'idem potence, je ne peux pas implémenter la fonction incrément, par exemple ?

Il faut préciser en disant qu'on ne peut pas la réaliser côté serveur. D'ume manière générale, il y a un surcoût lorsque l'on architecture un système sur REST. Nous sommes peut-être trop habitués à penser RPC et pas assez Ressource. Dès que l'on est bloqué en REST, il faut inventer une nouvelle ressource qui réalisera la fonction souhaitée.Par exemple, pour la gestion des transactions, on peut créer une ressource transaction qui possède un état et dont la représentation permettrait de confirmer la transaction ou l'annuler annuler. Vous pouvez lire le thread suivant : [xml-dev] A question about REST and transaction isolation (en anglais) qui date de février 2004, et oui, il y a cinq ans !A la différence des services web RPC classiques, REST ne propose donc pas de solution native pour répondre à la problématique des transactions applicatives. Si on en a besoin, il faut analyser son besoin transactionnel et l'implémenter grâce à une ressource.

4. Je dois donc juste faire un choix de framework pour commencer à développer avec REST.

Oui, c'est un bon point d'entrée. Et il ne faut pas non plus négliger le choix du framework de marshalling qui a un impact direct sur la quantité de code applicatif à développer. Un client disait qu'il était tenté de se passer de framework puisqu'on était sur les bases du web, et c'est vrai, on pourrait se contenter de l'API Servlet dans le monde java par exemple. Cependant, dès que l'on va commencer à écrire ses servlet REST, il va y avoir du code en commun: la gestion des header, la représentation des ressources en flux Json ou XML par exemple. Il y a donc bel et bien la place pour un framework REST ici. Nous avons déjà des expériences sur le choix à faire et nous pouvons vous aider.

5. Avec REST, on doit exposer ses objets métiers de trop de formats différent: XML ad-hoc, XML générique RSS ou Atom, Json...

La multi-représentabilité est aussi une force. Si vous choississez Atom par exemple, vous bénéficiez de tous les clients Atom déjà développés : clients lourds, intégration dans les portails, etc. Vos données disposent alors d'une diffusabilité maximale.De même, si vos utilisateurs sont déjà des consommateurs de pages WEB, de flux RSS, ils retrouveront des applications familières. Si on va jusqu'au bout, les outils de Mashups qui cherchent a laisser l'utilisateur libre de construire lui-même les services dont il a besoin, seront friands des ressources REST à consommer.

6. REST est l'architecture utilisée par le WEB actuel. Mais dans mon S.I., je n'ai pas besoin que ma donnée fasse trois fois le tour de la Terre avant d'être consommé par un employé...

Le fait que le WEB soit un réseau mondial n'est pas ce qui nous intéresse pour les application métier. Le vrai critère ici, c'est plutôt la propriété de montée en charge qui a son importance pour les S.I. A l'heure du Cloud Computing (que les vendeurs de solutions hébergées ont bien du mal à évangéliser), un S.I. bâtit sur REST à l'opportunité de bénéficier de la robustesse de tous les équipements et stratégies qui rendent le WEB performant:

• proxy
• cache (Cache-Control, ETag)
• compression des requêtes (Accept-Encoding / Content-Encoding)

REST est une approche rafraichissante dans le monde très server-side de Java aujourd'hui. Ce style architectural résonne d'une tonalité très actuelle en 2009 sur les architectures où la performance, la montée en charge et la robustesse à la perte de connexion en situation de mobilité sont des critères de plus en plus porteurs de valeur pour les applications que nous concevons. Les RIAs seront tout particulièrement intéressées par la consommation des services possédants de telles qualités.

Pour en savoir plus, vous pouvez venir au prochain Valtech AfterWork qui abordera le sujet SOA (précisions sur ce précédent billet).

---