Thumb-rules to decide between web service implementations: SOAP / REST?

Question

Are there any thumb-rules to decide between two schools of thought: SOAP and REST?

Answer 1

It depends on a lot of factors. One is not better than the other. Here is a list of differences I wrote before.

Answer 2

This isn't "thumb rules", but David Chappell gave a fantastic presentation on SOAP vs. REST at the ESRI DevSummit keynote this year. If you've got some time, I highly recommend listening to it.

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

Answer 3

First of all, while SOAP is specifically a web-oriented technology, REST has nothing to do with HTTP, but is still well-suited for web services. REST is also an architecture rather than a protocol, which SOAP is. So there are many ways to implement a RESTful service, as long as they adhere to the architecture's constraints.

REST fits much better into the traditional HTTP stack since it demands correct usage of protocols, when possible. SOAP merely uses HTTP as a sort of wrapper/proxy around its own protocol, which is not what HTTP is intended for. SOAP tries to get around limitations of HTTP, but it doesn't take advantage of much of what HTTP has to offer.

For example, cache servers sitting in the middle of a client and the content server should be able to cache requests and responses without understanding anything about the contents of each, which is not possible with SOAP, since the actual content that needs to be cached is a subset of the HTTP message's content, inside a bunch of SOAP wrappers and proprietary structure. RESTful services don't have this issue, so they scale much more naturally.

For the best source of information on REST, read Fielding's dissertation, and his blog, where he clears up common misconceptions. (He's the guy that created the REST specifications)