Le principal avantage de REST face à SOAP, a mon sens, c’est qu’il suffit d’avoir une plateforme existante sachant traiter du XML et exploiter HTTP, et c’est souvent le cas.

Avec SOAP, il est nécessaire de faire évoluer la plateforme pour ne pas avoir à tout faire soi-même, que ce soit en changeant de version ou en ajoutant un framework complémentaire. En environnement professionnel, cela peut être difficile voir impossible.

Le problème de REST par contre, c’est qu’il faut beaucoup plus être verbeux dans la documentation des services offerts, puisqu’il n’y a pas de formalisme standard de description équivalent à WSDL.

Mmm… Je pense que nous ne sommes pas d’accord. En effet, de mon point de vue, la “manière” (c’est plus une manière de faire qu’une technologie) REST de faire des services web me semble faciliter l’intégration des-dits services par des partenaires n’ayant pas participé à leur spécification, i.e. par des “retardataires”. Autrement dit : avec les services de type RPC, on expose une interface de programmation auquel le partenaire devra apprendre à “se brancher” si il n’a pas influencé la conception de cette interface de manière à se qu’elle se branche facilement sur ses propres systèmes. A contrario, dans le style REST, l’idée est d’exposer une interface de style “documentaire”, autrement dit d’exposer des ressources qui se présentent comme si elles étaient passives. Le partenaire qui n’a pas participé à la conception n’a plus alors qu’à “ramasser” les ressources en question. Et si celles-ci ont effectivement été mises en place selon les règles de l’art REST, elles contiennent leur propre mode d’emploi : leur sémantique est explicite ! Inutile alors de recourir à des NORMES supplémentaires telles que WSDL pour le mode d’emploi du service ou à UDDI pour l’inscription dans un annuaire de service.

> Quand à la technologie, en elle même, prenez REST et vous devrez vous en
> contenter. Prennez XML Protocol et vous avez la guarantie (pérénité) d’avoir une
> NORME amenée à prendre en compte vos futurs besoins tel la sécurité, la
> fiabilité, l’adressage (bref tous le reste :)) grâce à son EXTENSIBILITE.

Mon point de vue est que les normes de la famille SOAP ne sont pas forcément utiles dans la mesure où les normes existantes (HTTP, XML, RDF, …) sont plus stables, plus pérennes, et couvrent aussi bien tous les besoins futurs de sécurité, de fiabilité, d’adressage et fournissent déjà toute l’extensibilité requise.

La seule véritable nouveauté apportée par la famille SOAP est l’indépendance du transport sous-jacent (HTTP, SMTP, …) ce qui permettrait de faire des services web aussi bien accessibles via SMTP que via HTTP. Mais je ne crois pas que les cas d’utilisations correspondants soient suffisament courant pour justifier de l’intérêt de ces normes.

> Soit dit en passant la chronique CleverAge est en effet plutôt bien… mais alors
> Foward Motion ou Stop Energy ???

Euh… C’est-à-dire ? Que faire ? Eh bien, pour ma part, je mise sur les services web. Je choisis simplement de continuer une architecture qui a fait ses preuves : celle du WWW (aka REST) et j’évite tant que je peux m’en passer les complications à la mode (SOAP, …) ; au contraire, je mise pour aller plus loin sur RDF, OWL et Cie.

Quand à la technologie, en elle même, prenez REST et vous devrez vous en contenter. Prennez XML Protocol et vous avez la guarantie (pérénité) d’avoir une NORME amenée à prendre en compte vos futurs besoins tel la sécurité, la fiabilité, l’adressage (bref tous le reste :)) grâce à son EXTENSIBILITE.

Soit dit en passant la chronique CleverAge est en effet plutôt bien… mais alors Foward Motion ou Stop Energy ???