Les Carnets de Vol continuent ! Le premier post de cette série consacrée à REST nous a permis de définir la notion de Ressource. Ce deuxième post est consacré à la notion d’URI, ou Uniform Resource Identifier.

Notion d’URI

On peut définir simplement un URI comme étant à la fois le nom et l’adresse d’une Ressource. En effet, comme nous l’indique Roy Fielding dans sa thèse où il définit REST :

« Resource identifier [allows] to identify the particular resource involved in an interaction between components» 

En effet, rappelons la définition de Ressource que nous avons donnée dans le post précédent : peut être une ressource tout objet assez important pour être référencé en tant que tel. Dans cette optique, l’URI d’une Ressource est justement le moyen de référencer cette Ressource.

Un URI identifie une Ressource donc n’est rattaché qu’à cette seule Ressource. Mais une Ressource peut être rattachée à plusieurs URI. En pratique, on essaie tout de même de limiter le nombre d’URI rattachés à une Ressource afin de ne pas réduire leur valeur.

Et voilà, à ce stade, nous pourrions presque terminer ce post. Mais nous constatons souvent des confusions autour de cette notion qui est bien plus complexe qu’elle ne paraît, en particulier dans ce qui caractérise la relation entre un URI et sa Ressource.

Persistance des URI

Voici un premier sujet de confusions. La recommandation « Architecture of the World Wide Web, Volume One» du W3C, co-rédigée par Roy Fielding, nous explique l’importance de la notion de persistance des URI, dont elle donne une définition :

« the term URI persistence is used to describe the desirable property that, once associated with a resource, a URI should continue indefinitely to refer to that resource» 

Cette règle est simple : les URI doivent être affectés durablement.

Ce principe est cependant parfois mal compris. Ainsi, on peut parfois lire ou entendre qu’il y a un cas intéressant de non respect de cette règle :

• l’URI http://www.aeon-consulting.fr/an-application/1.0 pointe vers la Ressource « Version 1.0 de l’application ‘an application’»  de manière définitive
• l’URI http://www.aeon-consulting.fr/an-application/last pointe vers la Ressource « Dernière version de l’application ‘an application’» , qui peut correspondre de manière temporaire à la Ressource précédente (tant que la version 1.0 de l’application est la version la plus récente).

Il s’agirait là d’une utilisation pertinente d’un URI non persistant. Cette vision est erronée car la Ressource « Dernière version de l’application ‘an application’»  n’est pas la même que la Ressource « Version 1.0 de l’application ‘an application’»  : il s’agit de deux objets distincts. La confusion vient simplement du fait que temporairement, ces deux URI permettent de récupérer deux représentations identiques.

Notons que si nécessaire, le protocole HTTP fournit les mécanismes de redirection qui permettent d’indiquer aux agents que l’URI d’une Ressource a changé (via les codes 3XX des réponses HTTP).

Signification des URI

Signification des URI et état des Ressources

Utilisation d’URI significatifs, ou transparents

Dans le Web que nous utilisons tous les jours, on trouve fréquemment des URI significatifs : en effet, la connaissance de l’URI d’une Ressource parente nous permet (presque !) de retrouver les URI des Ressources filles qui nous intéressent. Il est donc naturel de suggérer pour nos Ressources des URI structurés, significatifs et descriptifs, voire même prévisibles.

Voici à titre d’exemple l’URI d’un article de ce blog, très significatif pusqu’il porte la date et le titre de l’article :

http://…/blog/2009/07/08/comprendre-rest-partie-1-ressource/

Utilisation d’URI non significatifs, ou opaques

La même recommandation du W3C nous indique qu’un URI n’est pas nécessairement significatif :

« The choice of syntax for global identifiers is somewhat arbitrary, it is their global scope that is important» 

Il s’agit du principe d’opacité des URI : un URI est un identifiant, il sert uniquement à identifier une Ressource pour permettre de la référencer. Il ne doit pas servir à donner des informations sur l’état de la Ressource, ce sont les Représentations de la Ressource qui jouent ce rôle, comme nous l’indique ce même document :

« It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations, not identifiers» 

Nous reviendrons ultérieurement sur la notion de Représentation. Voici à titre d’exemple une version opaque de l’URI de notre article de blog :

http://…/blog/126/

Cet URI est opaque car il porte un identifiant technique et non plus la date et le titre de l’article (qui sont des informations sur l’état de la Ressource article, qui peuvent en outre évoluer et donc violer la règle de persistance énoncée précédemment).

Un peu de recul…

Mais alors, que choisir entre URI significatifs et URI opaques ? En fait REST n’interdit pas l’utilisation d’URI significatifs, la contrainte est uniquement dans le fait qu’une Ressource doit avoir un identifiant. Le choix entre opacité et transparence des URI est et restera un sujet subjectif. Bien souvent, c’est la sémantique que l’on souhaite mettre en place dans la construction des URI qui permettra de faire un choix.

Signification des URI et format de Représentation des Ressources

Un URI ne doit pas servir à donner des informations sur le format de représentation de la Ressource :

« In general, one cannot determine the type of a resource representation by inspecting a URI for that resource. For example, the ‘.html’ at the end of ‘http://example.com/page.html’ provides no guarantee that representations of the identified resource will be served with the Internet media type ‘text/html’. The publisher is free to allocate identifiers and define how they are served» 

En effet, ce rôle est notamment assuré par la Négociation de contenu, qui fera l’objet d’un post ultérieur. Cette règle très importante n’est pas intuitive car elle n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Signification des URI et actions opérées sur les Ressources

De la même manière, un URI ne doit pas servir à donner des informations sur les actions opérées sur les Ressources : c’est la méthode HTTP qui joue ce rôle, comme nous le verrons dans un post ultérieur dédié à la notion d’Interface uniforme. Là encore, cette règle très importante n’est pas intuitive car elle non plus n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Syntaxe des URI

Sur ce point, REST n’impose rien explicitement. Cependant, les règles suivantes de syntaxe sont souvent mises en œuvre :

• utilisation du caractère ‘/’ pour aller du niveau le plus général au niveau le plus spécifique : /Dossier1/Fichier2 par exemple
• utilisation du caractère ‘,’ pour indiquer des éléments ordonnés : /coordonnees/43.55197,1.489613 par exemple
• utilisation du caractère ‘;’ pour indiquer des éléments non ordonnés : /couleurs/bleu;vert par exemple
• utilisation des caractères ‘?’ et ‘&’ pour indiquer des paramètres, souvent pour des Ressources générées dynamiquement : /search?q=aeon&hl=fr

Ajoutons que la limitation de la taille des URI à 256 caractères est loin derrière nous : les serveurs ont aujourd’hui des limitations de quelques milliers de caractères.

Mais au fait, quel est le lien entre URI et URL ?

Le terme URI fait penser à un terme bien connu dans le Web que nous utilisons tous les jours : URL (Uniform Resource Locator).

Quelle est donc la différence entre ces deux termes très proches, souvent amalgamés ? La RFC 2396, qui définit la syntaxe des URI, nous donne une réponse explicite :

« A URI can be further classified as a locator, a name, or both. The term « Uniform Resource Locator»  (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network « location» ), rather than identifying the resource by name or by some other attribute(s) of that resource» 

Les puristes REST auront peut-être repéré que dans cet article, on a davantage évoqué « REST appliqué à HTTP»  que « REST tout court» . Il s’agit d’un choix volontaire : d’une part, rappelons que le Web est une application des principes REST (et non l’inverse). HTTP 1.1 a été conçu afin de permettre cette application. D’autre part, cela permet de donner un aspect pragmatique à ces explications, dont le but est de clarifier les caractéristiques de REST.