Beware RESTifarianism as a religion.
REST is an approach or paradigm that in implementation is nearly always linked with the HTTP protocol. You could actually take a REST approach with many other technologies even SOAP.
Both support a Document oriented approach to information exchange and SOAP also supports an RPC oriented approach.
If you want to do something basic then a HTTP/REST message would differ from the equivalent HTTP/SOAP message by 3 HTML elements. i.e. not by much.
If you want to do something complicated, e.g. message level security, reliable messaging, event based exchange, asynchronous messaging etc. then with SOAP you would select the appropriate public standard specification. With REST you would have to invent your own way to do it.
The assertion that the Internet is REST based and scales well because of this is faulty as most of the web pages we actually use are usually stateful using cookies and other technology , also you will find that only two of the REST verbs work reliably over most of the Internet. The challenge of making a web application scale is basically the same irrespective of technology, the more you can defer or remove the handling of state the better the application will scale. A REST based approach to automation of a very statefull process will still have scalability problems to solve.
REST is appropriate where the problem is simple, where QoS can be at 'best effort' and the number of consumers creating their own clients it high. It is better when use to manipulate documents than when used to perform controls
Personally when I have the option I choose to use SOAP as it comes with a toolkit of associated public standards that means I don't have to re-invent the wheel. However I'm working B2B and enterprise back office and need a lot of these capabilities. If I were working in Business to Consumer and Web Front end and wanted my services to be 'mashed up' by as many people as possible, I'd at the very least provide a REST option.
Biting the hand that feeds IT
