I've been in a bit of a debate regarding SOAP vs. REST web service interfaces. I found this post on why Google is dropping their SOAP search API. Here's an excerpt :
http://blogoscoped.com/archive/2009-03-03-n84.html
The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don't just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle.
I have a fair amount of experience with the eBay web services API. In my experience, the SOAP interface suffered from from the above brittleness.
The eBay API is a complex, multi-lingual, multi-national beast with intricate business rules. eBay releases new planned SOAP WSDLs released every two weeks, with old WSDLs supported for 18 months. eBay uses a lot of tools to validate the WSDL, but issues would always sneak thru.
The nice thing about eBay is they also offer other interfaces like POX (plain ol' XML), JSON and REST services, so I tended to work with those interfaces.
I think SOAP has a nice "computer science" appeal to it, and many platforms have "built-in" SOAP support so it can be easy to get something up and running with SOAP. I think SOAP can be fine for smaller, more static uses, but it's not a panacea.