Sean Gillies publie régulièrement des articles pour le développement d'API RESTFull pour les Systèmes d'Information Géographique (SIG). Dans certaines de ses publications, il peut paraître virulent envers les Web Services de l'OGC. Il a d'ailleurs été interpellé sur Twitter à ce propros et de la manière suivante :
@sgillies What's the beef with OGC WMS and WFS?
Et comme sa réponse ne tenait pas dans un tweet (140 charactères), il a rédigé ce post : What's the beef ?
Avant de parler de son problème avec les Web Services de l'OGC, je souhaite revenir sur les articles qui ont fait naître cette intérogation.
Dans cette article, Sean discute de la différence entre service et ressource web. D'après le W3C, une ressource Web est identifiée par une URI et les agents intéragissent avec elles en envoyant des messages à celles-ci afin (par exemple) d'obtenir une représentation, ce qui peut se représenté ainsi :
Et dans le cas d'un Web Service OGC, la figure donne ceci (Sean utilise le service Geobase comme exemple, puisqu'il est représentatif des Web Service OGC) :
Sean pose donc la question suivante : Est-ce que l'URL de la "resource en ligne" du service (http://www.geobase.ca/wms-bin/cubeserv.cgi) permet d'identifier la ressource du service Web ? La réponse n'étant pas évidente Sean a interrogé cette URL :
seang$ curl -i http://wms.geobase.ca/wms-bin/cubeserv.cgi?
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2009 20:48:08 GMT
Server: Apache/2.0.52 (Red Hat)
Connection: close
Transfer-Encoding: chunked
Content-Type: application/vnd.ogc.se+xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<ServiceExceptionReport version="1.1.3" xmlns="http://www.opengis.net/ows"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/ows ...">
<ServiceException>
CubeSERV-35000: Missing REQUEST parameter
(raised in function handleWmsRequest() of file "main.c" line 422)
</ServiceException>
</ServiceExceptionReport>
La réponse étant de type '200 OK', d'après la norme RFC 2616, section 10.2.1, celle-ci est bien la représentation de la ressource identifié par l'url http://www.geobase.ca/wms-bin/cubeserv.cgi. Cette représentation a un contenu de type application/vnd.ogc.se+xml qui est une rapport d'erreur! Donc cette url http://www.geobase.ca/wms-bin/cubeserv.cgi n'identifie pas un service mais un rapport d'erreur du service. Et c'est la même chose pour tous les service Web respectant les normes de l'OGC.
Il se trouve que les Web Services de l'OGC ont été conçu comme une architecture indépendante du Web, même si de nos jours le Web est le principal tuyaux de transmission (middleware, selon Paul Prescod, ou DCP selon la documentation OGC), et que les Online Resource URL (URL de la resource en ligne) ne sont pas réellement des identificateurs universelles au sens du Web.
A mon avis pour que ces URL identifies une resource d'un service, il faudrait que sa représentation liste et présente les services disponibles.
Dans ce billet Sean ne fait que cité un article sur la mise en oeuvre d'une API REST avec MapGuide dans le cadre d'une application géographique pour la ville de Nanaimo. Par contre il utilisera cette démonstration dans le post suivant.
Dans cette article Sean utilise l'annonce faite par Nanaimo d'un SIG vraiment Web comme une occasion de démonter quelques mythes sur le REST et le Web, et de leur aptitude à concevoir des solutions de rechange à l'architecture des services OGC. Il liste donc quelques mythes et y répond!
- Les services Web RESTFull ne s'appuient pas sur des normes
Tout d'abord, il faut savoir que le REST est un type d'architecture particulièrement contraignante puisque c'est l'architecture du Wolrd Wide Web et que ce n'est pas une norme mais nécessite et s'appuie sur des normes. D'ailleurs l'interopérabilité dépend des normes, que votre architecture soit RESTfull ou non. Paul Prescod liste les types de normes :
In application-level networking, there are three basic things to be standardized
* Addressing -- how do we locate objects
* Methods or Verbs -- what can we ask objects to do
* Message payloads or Nouns -- what data can we pass to the objects to ask them to accomplish their goals
Dans le cas des services Web RESTfull, les 2 premiers types de normes sont normalisé par le protocol HTTP/1.1. Donc tout le problème de l'interopérabilité des services Web RESTfull se situe dans la troisième catégorie de normalisation : le message à charge utile. Ce qui d'après Sean est une décision consciente. L'intéropérabilité n'est pas quelque chose de parfaitement solvable, mais il est possible d'isolé les problèmes et l'architecture RESTfull aide à les résoudre. Il conseille d'ailleurs à tous de lire l'article de Prescod sur la normalisation, et de passer moins de temps à parler des 'qui' des normes dans les SIG discuter du comment et plus du quoi!
- Les services Web RESTfull ne sont pas des 'lights out' (lumières) accessibles.
En fait, les services RESTfull sont plus accessibles que les services OGC. Pour illustrer son propos Sean reprends l'analogie avec la lumière. Donc si vous mettez votre client spéciale OGC service dans le noir et qu'il ne trouve rien, Comment allez-vous accédez à votre service OGC ? Vous allez devoir vous battre avec d'autres outils de programmation Web dont aucun ne comprend la logique d'adressage et d'interaction des services OGC. Alors qu'avec un service RESTfull vous pouvez y accéder d'une façon normalisé (grâce au HTTP/1.1) avec curl, XHR ou n'imprte quoi d'autre qui vous fournira la description. Mais en tant que bon geek SIG votre client OGC est fermement attaché à votre service, mais si vous concidérez les autres agents du Web, ils ne peuvent pas les exploiter.
- REST est trop immature pour les SIG
Le Web est basé sur une architecture REST depuis 1994. HTTP/1.1 a été adopté en 1997. Le Web date de 1990. L'architecture des service OGC n'est pas plus mature.
- Les services Web RESTfull sont fait pour de petites solutions pas pour des solutions importantes et inter-agent
Le Wolrd Wide Web est notre application connecté la plus importante. Elle est à l'échelle mondiale. L'interopérabilité est assuré par l'utilisation des liens hypertextes. Donc sean pose la question suivante : On peut donc penser que les systèmes di'nformation géographique utilisant la même architecture serait capable d'atteindre la même échelle, non ?
Le résultat de cette article fut la question suivante : Mais quel est le problème avec les services Web OGC ?
Dernière article sur le sujet, et pour commencer Sean rappelle que la normalisation de l'OGC a du bon car elle a permis l'interopérabilité des systèmes d'information géographique.
Mais le problème qu'a Sean avec les services Web OGC c'est que leurs architectes n'ont pas fait leurs devoirs sur le Web. Car en dépit du terme Web dans le nom, les services OGC ne s'appuient pas sur l'architecture du Web et n'exploitent pas le protocole HTTP (HyperText Transfer Protocol). Les services OGC exploitent le Web comme un alchimiste comprend et utilise les éléments. On aurait pu éviter de réinventer la roue : "Update Sequence" au lieu d'expiration et validation HTTP, "Web Geolinking Service" au lieu d'une intéraction HTTP standard, ou encore "GeoDDS" au lien d'Atom. En dépit du fait que les Web Services OGC soient conçus pour être neutre du point du vue transport, HTTP est le seul "système distribué" significatif (que les architectures appellent transport). Quelques soient les exemples de service OGC, ils sont tous dépendant du protocole HTTP. Et pour tant il s ne sont pas vraiment Web!
A mon tour
Voilà toute l'histoire, et je partage un certain nombre de ses idées. Il y a d'ailleurs d'autres norme de l'OGC que je concidère comme non adaptée au Web, le GML pour ne pas le citer. Mais j'espère que les recherches et développements (GeoRSS, GeoJSON) effectués par la communauté en dehors de la fondation obtiendront une normalisation indiscutable.
