The computer industry has been doing electronic data interchange for years. Web services is a way of standardizing and turning it into Remote Procedure Calls, using ubiquitous web servers and XML. REST is a way of simplifying that, re-using existing HTTP protocols instead of inventing new ones.

The two giants of the Web, Amazon and Google, both concluded that UDDI and SOAP were not suitable for exposure in their Beta web services initiatives. Google layered a completely new, and much simpler custom library on top. Amazon provided thousands of lines of sample code in 35 Java files. But they also supported the REST approach which the overwhelming majority of their Beta users prefer.

Web services have always been led from in front by the evolving technology, not driven from behind by a pressing need. One result has been the profusion of industry groups rolling the frontiers forward, anticipating problems in advance of users encountering them. There are grand visions of automatically locating global services and connecting to them in real-time to consume billable services. But down on the ground, there are IT managers who just want the data from the customer repair system to flow to authorized service dealers so the dealers can order parts, and get reimbursement for warranty repairs. For these people UDDI, SOAP, and maybe WSDL is an unnecessary expense.

It would be trivial to reimplement the Google web service so that it used a REST approach, and there would no longer be any complexity that would need to be hidden. The Google developers are generally regarded as clueful, so one wonders if the web services team deliberately chose SOAP for a reason like “exploring a new technology”.

That question was posed on the Google developer newsgroup, and an official answer came back: “We chose to deliver Google Web APIs via SOAP because we believe that the SOAP developer tools make Google Web APIs accessible to the broadest developer community.” So they're claiming that they think the Java and .NET libraries that interface to SOAP outweigh simplicity. But then they wrapped the SOAP library with their own special easy-to-use library, which pretty clearly proclaims “we think SOAP is not ready for prime time exposure.” Time will tell if this was a well-considered decision. In the meantime, there are signs that Google will make a Beta3 release that supports REST.

SOAP itself has evolved over the years. Even the name has been retrospectively deemed no longer an acronym. While SOAP, UDDI and WSDL are solid, some standardization efforts in other areas of web services look premature.

It's debatable whether any advantages of SOAP are worth the increased effort and performance cost. Why use an elaborate SOAP message to communicate the remote method name and the parameters, when you can encode this in a URL? If you already know the service you want to use and its format, why use WSDL to repeat that information? In the face of changing technology, sticking to simple tried and tested mechanisms, like REST, is about as prudent as you can get.