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!
