SOAP vs. REST - why should you really care?

For many moons, the WS-* crowd, and the RESTafarians have argued. But what are the real differences in the two approaches? Although the argument is old, I still get asked for my opinion on this quite regularly - so here it is:

If you control the software at both the client and the server (sometimes known as the SOAP nodes ;) you can do whatever you'd like. In that case, you could choose to implement SOAP headers, or HTTP headers and no-one would know the difference. You can write your
own protocol, or use an existing one and extend it. A SOAP envelope is then "just an envelope". HTTP allows headers, and an "entity-body" - is an HTTP request or response then "just an envelope" too? Conversely, if you're writing an application that must talk with software written
by someone else, you'll need to support that interface, whatever it is.

So these days, other than out of necessity, why would someone offer a SOAP interface to their Web service?

• Will your interface be "bound" to more than one network transport? If you want to send SOAP+your interface over HTTP to some clients, and SOAP+your interface over BEEP to others, SOAP offers some independence from the underlying transport, but the abstraction is still leaky (see SOAPAction for example). Some would argue not only that the abstraction is useless, but that it is actually a hindrance to programmers.
  

• If others will develop software to talk to that interface, there are some almost-nice tools for creating SOAP/XML-based object "stubs" from XML (WSDL) files. These might make it easier to develop clients for a SOAP service. In my experience though, WSDL and XML descriptions can make only a poor substitute for talking to a human being and simply "following links". In other words, I'm not sure if there really is a short-cut to creating the code necessary to properly access any particular Web service (unless you are able to choose a good standard for your service, and find code that implements the standard, and works for you)
  

• There are several (WS-Security, WS-Trust, ID-WSF Authentication Service) well-documented ways of doing reasonable forms (beyond cleartext passwords) of authentication and simplified sign-on over SOAP. Of course, now that we have OAuth, what's the problem with authentication in an HTTP header?
  

• SOAP + BEEP allow you to create a single channel (ie. TCP socket connection) to send messages between two peers, rather than with the potentially more pedestrian HTTP method of requiring two peers to be running both a client and a server (and establish two channels) Beyond the cost of setting up two channels versus one (which may of course still be very important - espeically in an unreliable mobile network!), is there any other advantage to being able to create only one channel for two-way communication? How does SOAP + BEEP compare to XMPP in this regard?
  

When should you definitely not use SOAP?

• Would you like responses to be cached at the edge of your network, rather than retrieved, each time, from your database? Don't want to write your own caching proxy code? HTTP has this already.
  

• If your client is the common Web browser, SOAP doesn't make very much sense at all.