Anne Thomas Manes wrote:

Let's be concrete. With the HTTP version of Google' web service I can refer to any cached page with a URI:

* http://216.239.35.100/search?q=cache:www.manes.net

With the SOAP version *I cannot do so*. Cached pages retrieved through the SOAP interface *have no URI*. If the SOAP interface is removed, the URI version provides all of the same functionality. But if the URI version is removed I can no longer use XPath/XPointer/XSLT's "document" function to retrieve this. I can no longer use XInclude to refer to it. I can no longer use a cached Google document as an XML Namespace definition. I can no longer make RDF assertions about it.

The HTTP-GET version of the service is in a very strict, concrete sense, more powerful than the HTTP-POST/SOAP version.

The same goes for UDDI. Please forget that UDDI is about discovery. I'm not talking about the best way to do discovery. I'm talking about the best way to make a bunch of information available on the Web. UDDI repositories happen to be a "bunch of information." For all I care it could be a rap album database. An HTTP-GET/PUT/POST/DELETE version of UDDI, or the rap database, would be more powerful in a strict and concrete sense then the HTTP-POST/SOAP version. Thousands of people have heard this claim and not one has disputed it.

I could go down the list of web services at XMethods and demonstrate the same thing. Each can be made demonstrably and substantially more powerful if you base them on multiple HTTP methods rather than just one. It doesn't matter whether the service is read-only or read-write, the multiple-method HTTP version still wins. Thousands of people have heard this claim and I am waiting for the first counter-example.

I think we could have a very interesting conversation about this but I don't think it is the same conversation as whether SOAP should support more than one HTTP method.

Yes, I will separately send you an article that demonstrates this.

Just FYI, I've done more than look at the Google WSDL description. I rewrote it to use pure HTTP. (WSDL supports "pure" HTTP) I also wrote a server side application that maps from the HTTP version to the SOAP version. My version is a strict functional superset of the real Google version.

The other fascinating thing about it is that Google has three methods.

1. GetCachedPage. They *already* have an HTTP way to do this. They merely needed to descsribe it in WSDL and it would have been an official web service. For various reasons the HTTP version would be substantially more efficient and simpler.

2. SpellingCorrection. this one takes one string argument and returns one string argument. In order to do that, it builds two HTTP envelopes and two SOAP envelopes, although HTTP can trivially pass strings back and forth.

3. GoogleSearch. This one was provided in a XML/HTTP version around a year ago. That service became pay-only.

So they had their problem essentially solved a year ago and they had only to publish a WSDL. But instead they invented a less powerful, less efficient SOAP wrapper. That's progress!

There is no change in developer productivity. If you are using the .NET framework you take my version of the wsdl and you say:

delete GoogleSearch.wsdl ren Pauls.wsdl GoogleSearch.wsdl wsdl Pauls.wsdl

That generates a C# class which is identical to C# or VB programmers (actually there is a bug in Microsoft's WSDL implementation that prevents this from being strictly true -- but it is very close). If other WSDL implementations are similarly sophisticated (they aren't, yet) then the same will be true for them. I'm not theorizing. I have the code to prove it:

wsdl: http://www.prescod.net/rest/googleapi/GoogleHTTP.wsdl generated C# client (after a small bug fix): http://www.prescod.net/rest/PureXMLGoogleHTTPService.cs C# client code (same as shipped with the Google API): http://www.prescod.net/rest/googleapi/Form1.cs server implementation: http://www.prescod.net/rest/googleapi/google_gateway.zip

To be clear, the only thing that changed for the average developer is the classname. For clarity I created a different class name than Google's. But now the underlying service is based on GET (they had no need of PUT/POST/DELETE) and supports URI referencing.

I don't want to reference the web service. I want to reference the information WITHIN the web service. If it is a stock database, I want to reference *individual* stock quotes. If it is a UDDI repository then I want to reference individual T-Models. If it is a Google search then I want to reference individual search results (as I could a year ago, but cannot with the SOAP API). If it is an album database I want to reference individual albums.

This is not rocket science. It works on the Web as we know it. We now have a trend of people choosing to use SOAP because it is new and shiny and losing features that the Web provided them in 1993. We need to figure out how SOAP can add value to the Web's existing features and not detract or compete with them.