Don Box has an excellent post on the entire REST vs. SOAP debate entitled Pragmatics where he writes
The following design decisions are orthogonal, even though people often conflate two or more of them: Whether one uses SOAP or POX (plain-old-XML). Whether or not one publishes an XML schema for their formats. Whether or not one generates static language bindings from an XML schema. The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril. Whether one adopts a message-centric design approach or a resource-centric design approach. Some of the decisions (specifically 5) are architectural and sometimes philosophical. Some of the decisions (specifically 1-2) are simple business decisions that are determined by who your target audience is. If you want a great experience for .NET/Java devs, you’ll typically publish schemas (through wsdl) and support SOAP. If you want a great experience for LAMP folks, you’ll support POX messages and will provide a non-XSD description of your formats. If you want to reach both audiences, you’ll do both #1 and #2. If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.
This is so true it hurts. Most of the discussion around XML Web services has unfortunately been driven by platform vendors in either the Java or .NET camps which has unnecessarily skewed the discussion. When you are an actual business decision maker faced with building services on the Web, a lot of the silly dogma around REST vs. SOAP simply dissipates. Instead it boils down to deciding how broad of an audience you want to reach and how much work you want to do to reach that audience.
That said, I'd quibble about needing to do both REST and SOAP if you want to reach both the enterprise developer crowd (i.e. Java/.NET developers) and the LAMP crowd. One counter example to this theory is RSS, it is a RESTful web service which hasn't needed to be SOAP based to result in lots of great apps built on it using the .NET Framework such as SharpReader, RSS Bandit and NewsGator Outlook Edition. From my perspective as an RSS reader developer, I will admit that it would have taken a lot less code to handle the feed processing in RSS Bandit if it was SOAP-based. On the other hand, from my perspective as a service provider I'd note that the amount of work needed to implement and support two APIs that do the same thing is often not worth it.
Coincidentally, today is the date of my semi-regular lunches with Don and now he's provided some good fodder for us to chitchat about over MSFT's cafeteria grub.