I've implemented a small (in terms of number of supported calls) read-only web service which has SOAP+WSDL, REST/XML and REST/JSON frontends. From the server d

I've implemented a small (in terms of number of supported calls) read-only web service which has SOAP+WSDL, REST/XML and REST/JSON frontends. From the server development point of view: SOAP is a giant pain. Randomly selected SOAP implementations are just not likely to interoperate. We eventually coaxed PHP5's SOAP server stuff into talking to both .NET 2.0 and Java (with Netbeans 5.5's J2EE libs) clients - IIRC we recommend SOAP 1.0 for one, and SOAP 1.1 for the other. A week after we finished Netbeans 6.0 was released, and the SOAP client stuff that's bundled with it wouldn't play well with our server. From the client end: /if/ you can actually talk SOAP successfully, things work nicely. You just call the generated stubs and the RPC happens transparently. If I was calling our web service from C# I would choose SOAP every time. The REST stuff would be a pain to use if you had to use the DOM to read the XML that comes back, because, well, the DOM is painful. If parsing what comes back isn't a pain, REST works well. For internal clients, we prefer REST/JSON with the standard PHP json parser.