Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)

Anne Thomas Manes wrote:
> 
> Paul Prescod wrote:
> >
> > We're getting off into a diversion. Can we agree that every piece of
> > information available on the Web should be URL addressable or a PART of
> > a URL-addressable resource? And I don't mean part in a vague sense: I
> > mean you download a representation and the piece of information is in
> > there. In many content-types you can also directly link to
> > "sub-resources" of the resource (e.g. XML, PowerPoint, PDF)
> >
> 
> Agreed. In the case of a Web service, if you perform a simple GET on the
> resource, you receive a service description, which tells you how to (a) how
> to invoke the service or (b) how to send a message to the service.

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 encourage you to explore new ways to perform discovery. 

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.

>...
> Right now the most popular form of discovery of Web resources by humans is
> Google, although Google doesn't particular help you discover Web services (a
> very specialized form of Web resource). Google (until now) hasn't been
> particularly available to application (non-human)clients. By building a SOAP
> API to Google, applications can now invoke Google searches. I would
> characterize the Google SOAP API as extremely flexible and powerful -- so
> I'm having trouble following your argument. Are you saying that it could be
> more flexible and powerful (i.e., support simpler discovery) if Google
> designed a API based on something else other than SOAP?

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

> If you spend a moment looking at the Google WSDL description, you'll realize
> that the input and output messages are relatively complex. 

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!

> ... The data are
> structured and typed, and the formats change based on the function you're
> performing. From a developer's point of view, it much simpler to deal with
> these input and output messages as application structures than as URI
> constructs. I'm not sure that I'm willing to sacrifice developer
> productivity for a simpler discovery mechanism. 

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.

>...
> 
> Since Web services by definition are identified by a URI, you can easily
> reference a Web service. Our are you looking for more granularity -- I
> imagine that you're asking for a mechanism to supply a URI that provides
> access to a specific method within the service?
> There are ways to do so. You could provide a reference to a specific QName
> (referencing an operation within a portType) within the WSDL document.

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.

 Paul Prescod

Received on Tuesday, 23 April 2002 15:04:00 UTC