Faire du REST, ce n’est pas…

October 29, 2008 | In: Applications Web

Il y a de l’agitation dans l’air sur la planète REST ! Roy Fielding, l’inventeur de ce concept et l’un des auteurs principaux de la spécification du protocole HTTP, vient de poster deux articles du genre “coup de poing sur la table” sur son blog.

Avant de parler de ces deux posts, je vous invite à lire l’Introduction à REST et aux ROA que j’avais écrite il y a un an pour le blog Valtech : si vous ne connaissez pas REST, j’espère que cet article vous aidera à mieux comprendre les posts de Roy Fielding…

Aux Valtech Days, j’ai eu des échanges très intéressants sur REST avec plusieurs personnes : j’ai notamment été très heureux de rencontrer des personnes ayant comme moi mis en œuvre ces principes au sein de projets concrets, et de constater que nous partagions certaines idées pourtant méconnues ou sous-estimées. Pour résumer, concevoir une architecture RESTful, ce n’est pas uniquement exposer des services via HTTP : il y a plusieurs règles à respecter. En particulier :

1. Faire du REST, c’est utiliser tant que possible le protocole HTTP de manière standard afin de garantir la généricité des interfaces des services.

2. Faire du REST, c’est s’affranchir de la nécessité d’une description préalable des services : pour cela, il ne faut pas sous-estimer l’importance des liens hypertextes et des types de représentation des ressources.

3. Faire du REST, c’est repenser son SI en termes de ressources : si ce n’est pas toujours trivial (loin de là !), il s’agit d’un exercice très enrichissant.

Alors imaginez ma hâte lorsque j’ai découvert un post de Roy Fielding qui commence par la phrase suivante :

“I am getting frustrated by the number of people calling any HTTP-based interface a REST API”

Dans ce post du 20 octobre, il rappelle une série de règles non intuitives mais essentielles lorsqu’on conçoit une architecture RESTful. Ces règles rejoignent les trois points que j’ai évoqués.

1.  L’importance de l’utilisation standard du protocole HTTP pour assurer la généricité des interfaces

“A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols”

En effet, le problème est que bien souvent, des modifications à ce niveau sont révélatrices d’un design des interfaces qui est spécifique aux objets manipulés : les interfaces ne sont alors plus génériques.

2. La non-nécessité d’une description préalable des services et l’importance des liens hypertextes et des types de représentation des ressources

Il ne faut pas sous-estimer l’importance des types de représentation des ressources. Le client d’un service REST ne doit pas avoir besoin d’une description préalable du service, il doit pouvoir s’appuyer sur les types de représentation des ressources :

“A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type”

On me demande souvent de quelle manière les types de représentation des ressources peuvent-elles permettre au client de déterminer quelles opérations il peut effectuer sur quelles ressources. J’aime assez les exemples donnés par Roy Fielding dans l’un de ses commentaires :

“media type tells the client either what method to use (e.g., anchor implies GET) or how to determine the method to use (e.g., form element says to look in method attribute)”

Ces exemples sont appliqués au cas d’un client interprétant du HTML, mais on peut aisément les généraliser.

Il ne faut pas non plus sous-estimer l’importance des liens hypertextes. Le client d’un service REST ne doit pas avoir besoin d’une description préalable du service, c’est également en suivant les liens hypertextes proposés dans les représentations des ressources qu’il pourra déterminer quelles opérations il peut effectuer sur quelles ressources :

“A REST API should be entered with no prior knowledge beyond the initial URI [...] From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations.

En effet, les transitions doivent être permises par les liens hypertextes et non par des informations descriptives situées hors des représentations des ressources. Ce point, souvent occulté, est sujet à de nombreuses discussions entre les défenseurs de REST et ceux qui n’acceptent pas l’idée de ne pas se reposer sur une description des services (comme le WSDL le permet avec les services WS-*).

En fait, les représentations des ressources doivent être auto-descriptives, le client d’un service REST n’a pas à savoir quelle est la nature d’une ressource, il ne fait que manipuler une de ses représentations grâce aux liens hypertextes :

“Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links”

Lorsqu’on conçoit un service RESTful, il faut arriver à faire évoluer notre vision du modèle classique Request/Reply : si le client émet une requête afin d’obtenir des représentations de plusieurs ressources, la réponse du service ne doit pas contenir un ensemble de représentations (comme dans le modèle traditionnel), mais un ensemble de liens permettant d’accéder à chacune de ces représentations :

“Query results are represented by a list of links with summary information, not by arrays of object representations”

3. Sur la difficulté de concevoir une Architecture Orientée Ressources

En lisant ce post de Roy Fieding, on réalise la difficulté de concevoir des services RESTful. Ceux qui pensent que faire du REST c’est uniquement exposer des services HTTP occultent des caractéristiques essentielles de REST, les intérêts inhérents à ces caractéristiques mais également les difficultés. Concevoir une Architecture Orientée Ressources n’est pas facile. Mais il s’agit là d’un exercice très enrichissant.

Ce post a suscité de nombreuses réactions car plutôt difficile à comprendre pour le profane. Il a donc posté quelques jours plus tard, le 24 octobre, un autre article dans lequel il explique sa démarche afin de répondre à ces critiques. Pour résumer, il part simplement du principe que ses lecteurs ont un certain niveau de formation et de compétences. Je laisse le soin à ses autres lecteurs de s’attarder sur ce point, j’ai souhaité citer ce post pour une autre raison.

Cette raison est qu’il est intéressant de constater que Roy Fielding explique lui-même que faire du REST n’est pas facile : le premier post évoquait un ensemble de règles non intuitives et donc méconnues, et celui-ci rappelle qu’il n’y a pas de recette standard pour concevoir une Architecture Orientée Ressources et que comme d’habitude tout dépend du contexte. Et surtout, que s’il est difficile de déterminer si une architecture est réellement RESTful, il est bien plus facile de savoir si elle ne l’est pas :

“I don’t try to tell them exactly what to do because, quite frankly, I don’t have anywhere near enough knowledge of their specific context to make such a decision. What I can do is tell them what isn’t REST or that doesn’t fit my definitions, because that is something about which I am guaranteed to know more than anyone else on this planet”

Toutefois, contrairement à Roy Fielding, je pense qu’il est important de trouver un moyen pour démocratiser ces idées, justement parce qu’elles sont méconnues et incomprises : j’espère pouvoir rédiger bientôt une sorte de checklist qui serait utilisable par les connaisseurs comme par les profanes. Le tout en essayant de faire preuve d’un peu plus d’ouverture… ;-)



1 Response to Faire du REST, ce n’est pas…

Avatar

Espace de François » Blog Archive » APIs RESTful et Marketing : l’avènement du REST-like

May 19th, 2009 at 01:14

[...] En outre, le format des représentations est lui aussi indiqué dans l’URI (voir le “.json”) au lieu de profiter des puissants mécanismes de négociation de contenu fournis par HTTP. Ceci dit, les réponses retournées semblent proposer quelques URIs (n’oublions pas l’importance de l’hypermédia). [...]

Comment Form