REST ou SOAP ?

Beaucoup de débats ont lieu sur le choix d'une architecture REST ou SOAP. La conclusion, c'est qu'il faut les deux, ça dépend de ce qu'on a besoin. Si votre consommateur de service est une application Web alors choisissez dans un premier temps une architecture type REST. Si vous faîtes de l'EDI (Echange de données informatisés) choisissez SOAP car vous avez des mécanismes de sécurité, de transaction et d'accusés de réception de base.

Quelques avantages de REST:

- séparation lecture / écriture
- caching HTTP sur GET/PUT/DELETE
- idempotence: GET/PUT/DELETE/HEAD, ce qui permet le bookmark en particulier
- compression
- grosse réponse, fichier binaire, SOAP Attachement c'est pas trop ça
- simplicité et ergonomie
- ressources donc différent format de réponse possibles: JSON / XML / Text / XHTML avec l'utilisation des content type
- expérience de navigation inégalable
- beaucoup plus simple à appeler pour des applications web

Limites:

- Sécurité point à point car HTTPS, pas les mécanismes de WS-Security, Federation SAML
- Pas de notion d'accusé de réception, de garantie de reception du message, WS-Reliable Messaging
- C'est synchone uniquement contrairement à WS-Adressing
- Peu d'outils par rapport à SOAP
- Pas de gestion des transactions distribuées comme WS-Transaction
- Moins cadré que SOAP pour les développeurs, on peut coder de la merde

D'une certaine façon, c'est pour cela que dans l'idéal, il faut pouvoir fournir les deux, c'est ce que font Amazon et Flickr

Microsoft propose REST dans ses solutions et la plupart des moteurs Webservice fournissent du faux-REST (Axis) ou du REST (CXF) et même java a sa JSR 311.