I am looking at the same issue. Seems to me that actually REST is quick and easy and good for lightweight calls and responses and great for debugging (what could be better than pumping a URL into a browser and seeing the response).
However where REST seems to fall down is to do with the fact that its not a standard (although it is comprised of standards). Most programming libraries have a way of inspecting a WSDL to automatically generate the client code needed to consume a SOAP based services. Thus far consuming REST based web services seems a more adhoc approach of writing an interface to match the calls that are possible. Making a manual http request then parsing the response. This in itself can be dangerous.
The beauty of SOAP is that once a WSDL is issued then business' can structure their logic aorund that set contract any change to the interface will change the wsdl. There isnt any room for manouvre. You can validate all requests against that WSDL. However because a WSDL doesnt properly describe a REST service then you have no defined way of agreeing on the interface for communication.
From a business perspective this does seem to leave the communication open to interpretation and change which seems like a bad idea.
The top 'Answer' in this thread seems to say that SOAP stands for Simple Object-oriented Access Protocol, however looking at wiki the O means Object not Object-oriented. They are different things.
I know this post is very old but thought I should respond with my own findings.
