Thumb-rules pour décider entre implémentations de service Web: SOAP/REST?

Question

Y a-t-il des règles de pouce pour décider entre deux écoles de pensée: SOAP et REST?

Answer 1

Cela dépend de beaucoup de facteurs. L'un n'est pas meilleur que l'autre. Here is a list of differences I wrote before.

Answer 2

Ce ne sont pas des «règles du pouce», mais David Chappell a donné une présentation fantastique sur SOAP vs REST lors du keynote DevSummit d'ESRI cette année. Si vous avez du temps, je vous recommande fortement de l'écouter.

http://www.esri.com/events/devsummit/sessions/keynote.html

Answer 3

tout d'abord, alors que SOAP est spécifiquement une technologie orientée Web, REST n'a rien à voir avec HTTP, mais il est encore bien adapté pour les services Web. REST est également une architecture plutôt qu'un protocole, ce que SOAP est. Il existe donc plusieurs façons d'implémenter un service RESTful, à condition de respecter les contraintes de l'architecture. REST s'intègre beaucoup mieux dans la pile HTTP traditionnelle, car elle exige une utilisation correcte des protocoles, lorsque cela est possible. SOAP utilise simplement HTTP comme une sorte de wrapper/proxy autour de son propre protocole, ce qui n'est pas ce à quoi le protocole HTTP est destiné. SOAP essaie de contourner les limitations de HTTP, mais il ne profite pas de la majeure partie de ce que HTTP a à offrir. Par exemple, les serveurs de cache situés au milieu d'un client et le serveur de contenu doivent pouvoir mettre en cache les requêtes et les réponses sans rien comprendre au contenu de chacun, ce qui n'est pas possible avec SOAP, puisque le contenu réel être mis en cache est un sous-ensemble du contenu du message HTTP, à l'intérieur d'un tas de wrappers SOAP et de structure propriétaire. Les services RESTful n'ont pas ce problème, ils évoluent beaucoup plus naturellement. Pour obtenir la meilleure source d'informations sur REST, lisez le dissertation de Fielding et son blog, où il élimine les idées fausses les plus courantes. (Il est le gars qui a créé les spécifications REST) ​​

Answer 4

En voici un: si vous n'avez pas d'autre utilisation que HTTP, REST sera probablement le meilleur choix.