Karl m'a demandé de parler de certains codes HTTP, en particulier 301 (Moved Permanently). Je le ferais plus tard. Le sujet du jour sera plus abstrait: "Qu'identifie une URI?".
Prenons le cas d'un vélo. Il existe la notion de vélo, mon vélo et, par exemple, une photo ou une description textuelle de mon vélo. Supposons que maintenant, la photo du vélo soit accessible par une URI (http://www.example.org/monvelo.jpg), la description en texte disponible à une autre URI (http://www.example.org/monvelo.txt), et une URI permettant de choisir automatiquement l'une ou l'autre de ces descriptions (http://www.example.org/description-de-mon-velo).
Un utilisateur va donc pouvoir récuperer une description textuelle ou picturale de mon vélo en effectuant un appel de méthode sur l'objet "description de mon vélo".
En supposant maintenant que l'URI correspondant aux descriptions ne serve pas a recuperer une description, peut-on dire qu'elle represente la notion de "mon vélo" ? Dans ce cas, on peut alors definir des méta données sur "mon vélo" et ces médonnées peuvent elles aussi être transférées.
Un des points défendu par les apôtres de REST est que tout ce qui est disponible sur le Web en lecture, doit utiliser la méthode HTTP GET. (Lire : chaque objet accessible sur le Web par HTTP, et donc l'interaction n'implique pas de changement d'état doit utiliser GET). Si on considére que l'URI correspondant a "mon vélo" existe, et avec elle, ses métadonnées, alors il existe un moyen de les recuperer, et donc forcement par la méthode GET.
Le choix de l'URI n'était pas anodin, j'ai pris une URI en "http" car c'est le moyen usuel de réperer l'information. Le fait d'utiliser HTTP entraine d'autres métadonnées, liées au protocole utilisé. Par exemple, quelles sont les méthodes que l'objet pointé par l'URI est capable de traiter? La maniere de récuperer cette information est l'utilisation de la méthode OPTIONS. Pourquoi dans ce cas ne pas utiliser GET? Pourquoi cette information ne serait pas présente dans les métadonnées de la resource? Tout simplement car il y a une différence entre la notion de "mon vélo" et la notion de "la vue de mon vélo par HTTP". Or cette distinction est implicite dans le fait d'ecrire l'URI, le choix du protocole est une information objective de l'URI, qui n'est donc plus un identifiant opaque d'une notion particulière ou d'un objet.
Par le choix du protocole, on identifie une "vue" spécifique au protocole choisi, et cette vue est différente de l'objet pointé. Donc les médonnées de cette vue sont differentes de celles de l'objet générique pointé. Il serait donc normal d'avoir les informations sur les possibilités du protocoles dans les métadonnées de cette vue. L'utilisation d'OPTIONS dans HTTP est une erreur de design, et la notion de "métadonnées d'une resource ou d'une URI" est incomplète si l'on omet qu'une URI contient une partie non-opaque.
On est encore plus loin de la notion abstraite de vélo comme veut le définir le Semantic Web. Il y a donc besoin de definir nouvel espace d'URI pour les descriptions abstraites, un besoin de complétude des métadonnées relatives à une vue particulière d'une resource, et la mise à plat de certains défauts de design de HTTP, résultat d'un manque de modèle abstrait.
Il est heureux que les travaux sur SOAP/1.2 aient commencé par la rédaction d'un modèle abstrait, qui est a mon sens le document le plus important produit lors de l'élaboration de SOAP/1.2.