Quand on débute un nouveau projet Web, avant toute autre chose, il faut définir les ressources qui le constitueront, les URI qui les identifient et leurs relations réciproques. Si ce travail est bien fait, tout le reste sera plus aisé, que ce soit l'implémentation technique ou la création des diverses représentations.

Cependant, ce travail essentiel n'est pas toujours simple et, de toutes les questions qui surgissent lors de la définition des URI, une en particulier revient souvent : Doit on inclure dans les URI des extensions de noms de fichiers ?

Environnement idéal et monde réel

Dans un environnement idéal (RESTFul disent les spécialistes), la réponse est simple : "Non !". En effet, comme nous l'avons vu dans un précédent billet, les URI identifient les ressources et non leurs représentations. Les extensions donnant une information concernant la représentation, elles n'ont rien à faire dans les URI.

Mais, après 20 ans de développement chaotique, le Web est loin d'être un environnement idéal. Nous devons donc nuancer la réponse. Nous avons deux cas de figure, selon le type d'information que nous donne cette extension.

Si l'extension indique la nature même de la représentation.

Ce sont les extensions suivantes : html (et htm, xhtml, xht), xml, rdf (et xrdf, n3, ttl), rss, atom, jpg (et jpeg), png, txt, etc.

Il est possible, mais pas obligatoire, de l'inclure dans l'URL car elle permet de suppléer à une absence de mécanisme de négociation de contenu.

Par exemple, si nous concevons un site sur les cocktails, la Margarita peut être identifiée par http://example.com/cocktail/margarita et sa représentation JPEG peut être récupérée directement à l'adresse http://example.com/cocktail/margarita.jpg. C'est simple et robuste.

Dans ce cas, il ne faut pas oublier de prévoir une représentation aussi quand aucune extension n'est précisée. Le plus souvent, il s'agira du HTML.

Si l'extension indique la technologie employée pour construire la représentation

Ce sont les extensions suivantes : php (et php3, phtml), asp (et aspx, axd, sps, asmx, mvc), cgi, psp (et py), pl, rb (et erb, rhtml), jsp (et jsf, seam, class, do), shtml (et shtm, stm), cfm, mvc, awp, etc.

Il ne faut jamais l'inclure dans l'URI. Principalement pour trois raisons :

• Il s'agit d'une information qui n'est propre ni à la ressource, ni à la représentation. Elle est juste liée aux choix techniques côté serveur. Elle n'est donc pas pertinente et obstrue l'URI.
• Elle affaiblit la pérennité des URI, car elle oblige à rester fidèle à la technologie serveur initialement choisie.
• Présenter ainsi à la vue de tous les technologies serveurs utilisées est une invitation à l'exploitation des failles qui leur sont associées. C'est une maladresse diminuant la sécurité du site.

Conclusion

Les extensions de noms de fichiers ne sont pas obligatoires et doivent apporter une information concernant uniquement la représentation. Par définition, elles ne concernent pas la ressource et elles ne doivent pas non plus concerner les technologies utilisées côté serveur.

Prendre le soin de bien définir les URI en début de projet, c'est désamorcer de nombreux problèmes structurels que les développeurs rencontreront lors de la mise en œuvre de ce projet.