In Summary:
REST is an approach, SOAP is a protocol. It is more appropriate to compare SOAP and POX. This said a comparison of these payload protocols is not very enlightening. You need to focus on the big architectural questions not the wire format. Key questions are a) whether there is a requirement for broad system-2-system level interoperability. b) Whether there are requirements for enterprise-level QOS.
In Detail:
Don Box does a good job of summarising the top-level issues @
http://www.pluralsight.com/blogs/dbox/archive/2006/02/17/18869.aspx. As Don points out the term REST is hugely overloaded and encompasses Resource-centric architecture, the use of POX, how interfaces are published etc. For the purpose of this response I am assuming you want to compare the relative merits/demerits of SOAP vs POX.
I would say that you dont want to get into the detail of the wire-level protocols. In general POX is a lighter and often more usable approach whereas SOAP is more powerful and more interoperable.
For me the tipping point in your decision centers around the extent to which the service you are offering is a publically exposed service. Put another way - the extent to which the service needs to be interopate with and be accessible from other development environments. As the good Mr Box implies - the broader the audience for your service the more flexible an approach you are going to have to take.
If the service that you are offering needs to be accessed by a variety of clients using technologies that you have no control over then SOAP may be the lowest common denominator because this approach is supported in most dev environments. REST may be preferable if you are implementing Web Services simply as a way of exposing components across a firewall and you have control of the clients that will be used to access the service.
There is also the issue of qualities of service. If you have requirements for multi-hop security then SOAP w/WS-Security is a good interoperable (if heavyweight) solution. If your service needs to participate in a distributed transaction then you may need something like SOAP w/WS-RM.
You should note that there are also a class of problems where the integration requirements are so broad that POX & SOAP access to services is not enough. I have blogged on this previously at
Caped Crusading: SaaS = Silo'ed Applications as Services?
John
