L'avenir du SIG Web est dans le REST mais plus dans le SOAP
Par René-Luc D'Hont le samedi 7 mars 2009, 00:12 - Système d'Information Géographique (SIG) - Lien permanent
Google vient d'abandonner son API SOAP (Simple Object Access Protocol) pour se concentrer sur ses API RESTful (Representational state transfer), et James Fee profite de l'occasion pour promouvoir le développement d'API REST
Ce qui est important avant d'aller plus loin c'est de bien caractériser les 2 types d'API. Pour ce faire j'ai trouver une très bonne comparaison faîtes par Geoff Zeiss :
The most attractive features of REST to me, and a major difference compared to SOAP (which unlike it's name suggests is not that simple) is that you do everything by URLs and the only web protocol you need is HTTP. This means among other things that RESTful Web services go through firewalls without special configuration.
dont voici une traduction :
La caractéristique du REST la plus intéressante pour moi et une différence majeur avec le SOAP (qui contrairement à ce que suggère son nom n'est pas aussi simple) est que vous faîtes tout via des URLs et le seul protocole Web dont vous avez besoin est HTTP. Cela signifie entre autres choses que les Web Services RESTful passe au travers des firewalls sans configuration spéciale.
Donc la différence principale entre les deux c'est qu'une API RESTful n'est rien d'autre que le Web, comme le dit régulièrement Sean Gillies, alors que l'API SOAP nécessite une mise en oeuvre autour du Web au d'autre chose.
Une fois cela poser, il semble évident que pour développer et promouvoir des solutions de SIG Web, il vaut mieux s'appuyer sur une API RESTful pour la communication entre le client et le serveur. Et le meilleur exemple que j'ai en tête c'est le passage de CartoWeb à MapFish. Avant de s'appeller MapFish, le nouveau projet de CampToCamp s'appellait CartoWeb 4.
Une des fonctionnalités intéressante de CartoWeb était la présence d'une API SOAP. D'après la documentation cette API permettait de dissocier CartoWeb client et CartoWeb Server. Elle aurait pu aussi être utiliser pour intégrer CartoWeb Server dans un système d'information plus complexe, ou alors pour être exploiter au sein d'un client tiers. J'ai d'ailleurs essayer de développer un client XUL, Firefox, pour CartoWeb exploitant cet API. J'ai rapidement abandonné l'idée par manque de documentation et d'intérêt pour une telle solution.
Dans MapFish, il n'y a plus d'API SOAP, mais une API REST, et MapFish n'est plus une simple solution de Web Mapping, mais un framework de développement d'application SIG Web!
Une autre raison de s'appuyer sur une API REST pour développer une application SIG Web, c'est l'innovation! Sean Gillies rapporte le point de vue de Steve Vinoski à propos de RESTful HTTP comme innovation perturbatrice dans IEEE Internet Computing :
RESTful HTTP, on the other hand, has all the makings of a disruptive technology to the RPC market. As RPC systems [ed: Sun RPC and Apollo NCS, DCE, Corba, RMI, J2EE, SOAP, and WS-*] moved up-market and gained capabilities and features over time to continue to satisfy the most demanding customers, they overshot more and more potential users who shunned the complexity and cost of such systems. In RESTful HTTP, which was born in the adjacent market of the World Wide Web and is a sustaining technology there, these overshot users are finding an approach that helps them build solutions that are less expensive, simpler to build, and easier to extend and maintain than what RPC approaches can offer. It's precisely these qualities that make RESTful HTTP a disruptive technology in this context.
que l'on peut traduire par :
D'autre part RESTful HTTP a tout ce qu'il faut pour être une technologie perturbatrice sur le marché du RPC (Remote Procedure Call). Les systèmes RPC [ex: Sun RPC et Apollo NCS, DCE, Corba, RMI, J2EE, SOAP et WS-*] ont fait progresser le marché et ont acquis les capacités et fonctionnalités au fil du temps pour continuer à satisfaire les clients les plus exigeants, ils ont dépassé de plus en plus d'utilisateurs potentiels qui ont boudé la complexité et le coût de ces systèmes. Dans le RESTful HTTP, qui est né dans le marché adjacent du World Wide Web et y est une technologie de base, ces utilisateurs dépassés ont trouvé une approche qui les aide à construire des solutions qui sont moins chères, plus simple à mettre en oeuvre, et plus simple à éteindre et maintenir que ce que peuvent offrir les approches RPC. Ce sont précisément ces qualités qui font de RESTful HTTP une technologie perturbatrice dans ce context.
Les API REST permettent d'innover et de proposer de nouvelles façons de distribuer et d'exploiter les données. Elles permettent de répondre aux besoins des utilisateurs finaux. Les systèmes mettant en oeuvre les contraintes du REST sont capables de changer d'échelle facilement et d'évoluer pour répondre aux besoins. C'est donc bien l'avenir pour les SIG Web!
Commentaires
Pas mal de buzz autour de REST et SOAP ces temps ;-) Il faut toutefois être prudent avec cette problématique car il y a eu souvent eu des propos mal interprétés ou erronés.
Sans prétendre à l'exhaustivité, voici quelques commentaires:
- Tout d'abord SOAP est un protocole alors que REST est un style d'architecture. Il est donc pas forcément évident de comparer 2 choses différentes par nature.
- REST permet de répondre à bon nombre de problématiques geospatiales et bon nombre de services OGC, bien que n'imposant pas REST (ni SOAP... du reste ;-), sont plutôt adaptés à une architecture REST. Le meilleur exemple étant WMS.
- SOAP souffre de l'imposition du XML, car son parsing en client léger pose des problèmes de performance. Par contre, il possède l'avantage d'avoir un langage de description WSDL. Mais REST rattrape son retard dans ce domaine: www.ibm.com/developerwork...
- SOAP peut tout à fait travailler à travers le protocole HTTP.
- Effectivement, MapFish a une API RESTFul. Les principes REST ont permis dans ce cas de développer une interface performante et simple à implémenter.
- Je ne voudrai toutefois pas jeter SOAP à la poubelle, car dans certains cas, comme le WPS, SOAP peut s'avérer être plus qu'une solution alternative. Le chaînage de procédure est également possible en SOAP alors qu'il est limité en REST.
Donc oui, REST a un bel avenir, mais SOAP n'est de loin pas mort.
Je souhaiterais ajouter que les W*S de l'OGC, dont le WMS, ne sont pas conçu suivant une architecture REST. Vous pouvez relire Sean Gillies et les Web Services de l'OGC.
Enfin, il ne faut oublier que l'architecture REST s'appuie sur une approche totalement différente des technologies RPC, ce en quoi elle est une tehnologie perturbatrice, et donc il est important de suivre les propositions que feront les éditeurs dans ce domaine.
Cédric, vous avez écrit:
"""Je ne voudrai toutefois pas jeter SOAP à la poubelle, car dans certains cas, comme le WPS, SOAP peut s'avérer être plus qu'une solution alternative. Le chaînage de procédure est également possible en SOAP alors qu'il est limité en REST."""
Le chaînage est omniprésent sur le Web: proxy servers, reverse proxies, etc. WPS, c'est un chose drôle ... dans "Le Cloud", processing devait prendre une forme plus proche de Yahoo Pipes, oui?
Sean, je ne vais pas me prononcer sur la drôlerie de WPS ainsi que sur Yahoo pipes que je ne connais pas en détail, mais par contre votre commentaire me permet de rebondir sur votre blog: sgillies.net/blog/881/unb... En effet, il est clair que l'ajout de proxy ou d'intelligence client dans une architecture REST permettent de chaîner à plus que 2 niveaux, mais cela ne sera pas forcément simple...
Bonjour,
Le Forum OGC France travaille à expliquer les enjeux de SOAP (et, partant, de REST) à des non informaticiens (dans le contexte INSPIRE). Le chaînage en question était le chaînage de service.
Pour ce que j'en ai compris, il y a consensus, au moins au Forum OGC France, et presque consensus à l'OGC, pour dire qu'il y a de la place à la fois pour SOAP et REST selon les besoins de chacun. Nous n'avons pas (encore) réussi à caractériser les emplois préférables de ces deux objets, mais schématiquement plus c'est compliqué et d'emploi peu fréquent, plus c'est adapté à SOAP, plus c'est simple et grand public et plus REST devient rentable.