Le navigateur Web est-il un client REST ? [Résolu]

Ce long post est résumable en une petite question :
comment appeler une représentation particulière d'une ressource depuis HTML ?

De l'enthousiasme au blocage

Comme certains ici, je me suis interessé à REST, l'architecture qui prétend utiliser les technos du Web à leur plein potentiel.

Voilà les principes de REST, tels que je les ai compris :
- l'URI est seulement nom, (presque) jamais une action
- à chaque URI correspond une unique ressource, à chaque ressource correspond une unique URI
- les pages HTML ne sont que des représentations de ces ressources
- les flux RSS, les fichiers XML et RDF divers, les images et autres fichiers multimédias sont d'autres représentations de ces ressources
- les représentations n'ont pas d'URI, car ce ne sont pas des ressources
- mais elles sont accessibles avec les headers HTTP, notamment Accept (types de contenu) et Accept-Language (langues)
- pour manipuler ces ressources, on utilise toutes les méthodes de HTTP : GET et POST, évidemment, mais aussi PUT et DELETE
- l'identification se fait par HTTP à chaque requête

Une fois bien renseigné, je me suis mis à programmer la partie serveur d'un mini CMS en Python et j'ai été conquis. Réfléchir en termes de ressources est très efficace et l'architecture obtenue est très belle. On confie plein de boulot à HTTP. J'ai vraiment eu l'impression de revenir aux sources du Web.

En suite, j'ai fait des tests avec l'extension firefox restclient et ça marche du tonnerre.

Cependant, les clients Web utilisés par les vrais gens ne sont pas d'obscurs clients REST mais les navigateurs (Firefox, IE, Opera...). Et là, catastrophe !

Un exemple

Un exemple : imaginons que je fais un site sur les Simpsons.
Je commence par lister les ressources :
http://example.com/simpsons/personnage/homer
http://example.com/simpsons/personnage/marge
http://example.com/simpsons/episode/45320
http://example.com/simpsons/lieu/centrale-nucleaire
etc...

Ensuite, je créé les résultats des différentes requêtes HTTP.

Notamment, pour la méthode GET, je défini les représentations selon les types de contenu :
- http://example.com/simpsons/personnage/homer a une représentation HTML mais aussi une représentation en FOAF/RDF et une représentation image en PNG
- La ressource http://example.com/simpsons/episode qui liste les épisodes a une représentation en HTML mais aussi une en Atom ou en RSS.
- Le fichier OpenSearch est une autre représentation de la ressource http://example.com/simpsons/search déjà représentée en HTML avec formulaire
Mais aussi selon les langues, car toutes les ressources de mon exemple ont des représentations en Anglais et en Français si possible.

Le problème

Le problème est que je ne sais pas comment appeler une représentation particulière d'une ressource depuis du HTML interprété par un navigateur Web.

<link href="">, <a href=""> et <img src=""> génèrent des requêtes HTTP GET mais ne permettent pas de spécifier les Headers HTTP.
C'est dommage, car je pensais que les attributs @TYPE et @HREFLANG servaient justement à ça.

En gros, je voudrais que sur la représentation HTML de http://example.com/simpsons/personnage/homer soit embarquée la représentation PNG en écrivant juste :

<img src="http://example.com/simpsons/personnage/homer" type="image/png" />

Je voudrais que sur la représentation HTML de http://example.com/simpsons/episode soit incluse une référence au fichier Atom ou RSS de cette manière :

<link rel="alternate" type="applictaion/atom+xml" href="http://example.com/simpsons/episode" />

Je voudrais pouvoir mettre un switcheur de langues aussi simplement que ceci :

<ul>
<li><a href="http://example.com/simpsons/episode/45320" hreflang="en">English</a></li>
<li><a href="http://example.com/simpsons/episode/45320" hreflang="fr">Français</a></li>
</ul>

Avec à chaque fois la même URI pour toutes les représentations.

Donc...

Ai-je compris l'architecture REST de travers ? Ou sont-ce les navigateurs qui n'exploitent pas les attributs sus-cité convenablement ?
Qu'en pensez-vous ?
Modifié par pierredureau (10 Nov 2009 - 08:49)

Bonjour,

Alors : les navigateurs ne connaissent pas PUT ni DELETE, c'est un fait.

Si mes souvenirs sont bons, d'après la spécification HTML, les attributs type et hreflang de l'élément IMG sont des "indications" de rendu pour le navigateur et n'envoient donc pas d'en-tête HTTP particulier. Donc, là, c'est plutôt HTML qui est en cause, et je ne suis pas sûr que ce soit une mauvaise chose.

J'utilise personnellement Ruby on Rails. Rails contourne les deux problèmes de la manière suivante :
- un champ caché dans un formulaire envoyé par POST indique la méthode souhaitée, dans le cas de PUT ou DELETE.
- le format du fichier envoyé est dépendant de l'extension du fichier par défaut, ou d'une autre partie de l'URI. Dans l'exemple d'Homer, on aurait donc
http://example.com/simpsons/personnage/homer.html
http://example.com/simpsons/personnage/homer.png
http://example.com/simpsons/personnage/homer.rdf ...

Quant à la langue, le mieux est encore d'utiliser les préférences du navigateur, et deux URI différentes. (Mais qui vient d'évoquer le référencement ?)
Question existentielle : la même ressource dans deux langues différentes (et donc deux cultures), est-ce vraiment la même ressource ?

Voilà. Espérant avoir aidé un peu.
Modifié par Lanza (09 Nov 2009 - 19:42)

Bonjour,

HTML4: 1998
REST: 2000

Donc voilà.

@Florent V. : REST étant juste une architecture basée sur des technologies datant du début du Web (HTTP et ses méthodes, URL/URI et HTML comme représentation principale des ressources), je ne pense pas que cette comparaison de dates soit pertinente. Les éditeurs de HTML4 connaissait HTTP, rien ne les empêchait d'inclure par exemple les méthodes PUT et DELETE dans <form />.

@Lanza : Merci pour ta réponse complète.

En ce qui concerne les méthodes dans les formulaires, ce n'est pas vraiment un souci car :
- comme tu le dis, on peut simuler avec un champ hidden (je le fais déjà)
- HTML5 prévoit de les inclure

C'est plutôt les URL propres à chaque représentation qui me chagrinaient. Mais je me fais une raison car :
- il est clair que les liens HTML n'ont pas été conçus pour transporter d'autres informations que l'URI
- une seule URI par ressource peut poser des problèmes ergonomiques : 1) je visualise une représentation PNG d'une ressource, je transmet son URI par mail. Mon correspondant l'ouvre hors contexte de navigation : il tombe sur la représentation HTML ! 2) Je fait un PUT sur une ressource qui a plusieurs représentations basées sur XML et générées à la volée, mais aussi une représentation PDF. Toutes se mettent à jour sauf la PDF !
- finalement, l'idée d'attribuer une URI à la fois à la ressource (sans extension :
http://example.com/simpsons/personnage/homer ) et à ses représentations (avec extension : http://example.com/simpsons/personnage/homer.html ) est pas si mal.

Cordialement
Modifié par pierredureau (10 Nov 2009 - 08:49)