After a glib commenter suggested I do some more reading about REST before I bash it so much, I took his advice. I read, and read, and read... Did my opinion change?
Not so much.
A lot of the debate in the REST/SOAP camp seems a little odd to me... the REST folks complain about SOAP being complex and weird... but that's not SOAP's fault. That's the fault of Microsoft and the W3C for trying to complicate matters beyond necessity. If you don't like it, don't use it.
Then there are the Talmudic debates about using POST versus PUT, which HTTP error code to use, or even encouraging Remote Procedure Calls (RPC)... those are mostly silly.
So, I'm going to add three more big reasons why REST gives me the willies:
Resources Versus Services
A web API should be somewhat analogous to a graphical interface: event driven. I click a button, and it does a thing. What does it do? I don't care... as long as its exactly what I want, I'm happy.
Users are so fun!
The problem is that step 1 of a REST API means you have to find the resources you wish to modify, and then call the service. What if I don't know what resource I want to modify? What if I don't care if the resource is a uk-customer or a european-prospect, I just want to record some data about a dude I met in London?
Remote APIs should focus on the action, not the back-end implementation. Otherwise you'll be tempted to use RPC, which is the exact opposite of good SOA.
If you force the user of the remote API to know what resource it is, then you lose some flexibility. What if you want the back-end system to decide what the resource is? Maybe it should be different based on the context of the request, and the user's credentials? What if you upgrade your system, and change the back-end implementation to use different resource names?
To avoid problems, you must force yourself to push more and more abstract resource names to the front end... which means you lose a lot of the value of named resources. The ultimate endpoint is when you have one resource named resource that takes an action parameter... at which point you're pretty much just doing SOAP.
Implied Resource Hierarchy/Taxonomy
If you have a small system, using named resources may work just fine. And in that case, REST makes it easy to know what services work for what resources. I myself am a fan of human-readable documentation, but to each his own.
However... this sort of implied hierarchy also gives me the willies.
The web is most definitely not hierarchical. Every attempt I've seen to create a taxonomy for it has failed. Even single taxonomies of intranets are unworkable. Look at Amazon.com for example. Every book is in multiple taxonomies, to aid in how people choose to browse for their options.
Extending this to REST, what if you want one service to update 10 resources simultaneously? What if the name and type of these resources changes on the fly? What if you're only allowed to choose 8 of the resources, the other 2 determined for you by the back-end system? What is the clear an unambiguous REST URL for that?
If its service-oriented, you'd call a service named FunkyActionOnTheseResources, then pass in ten (or eight) resource IDs as XML nodes. Done and done.
No taxonomy, no worries. But of course, you'll need to document them better... but that's always helpful.
HTTP Is Kind Of Broken
The REST people ask one interesting question: why does SOAP tunnel through HTTP, when HTTP is fine as it is? Well, because HTTP is not fine as it is. It is broken in lots of little ways which may seem minor, but can cause huge problems. You do lose something with tunneling, such as caching in browsers or reverse-proxies... but you gain control. And obviously, there is more than one way to implement a cache.
My personal big gripe is that there is a HTTP header for the encoding of the content, but not the encoding of the header! If I have a Japanese user name in the HTTP header, how do I know if its encoded with utf8, utf16 or shift_jis? I don't! You literally have to cross your fingers and pray. When it comes to logins, being helpful is a security hole.
And what happens if your browser gets a 404 error message? Does it display the actual response from the web site, or one of those 'friendly error pages' from Microsoft? What if your intranet has a helpful policy that sends back an internal error page in the event of a 404? And who knows what fun will be had in the future...
I'm sorry, you just can't trust HTTP to do what you want. Even if its in the spec, that doesn't mean its used by the applications you rely on.
For maximum compatibility in the most number of environments, some data must be placed outside of HTTP headers, period. If you build a system that relies on people always following the spec, you will soon know misery.
Not The End
There are good ideas about simplicity in the REST camp... I feel that those ideas should be brought into SOAP, instead of abandoning it.
We should abandon WSDLs, data binding, and strong typing in SOAP. The only reason to have those is if you are trying to tunnel RPC through SOAP... RPC is already a bad idea, don't make it worse by forcing people to use XML to describe a binary data object!
Allowing SOAP responses through GET is a good idea, and its one Stellent implemented 3 years ago. It wasn't in the spec, but it Just Made Sense®, so we did it.
Who knows what will happen to SOAP... but if you have technology that can adapt faster than everybody else, you will win.