Example Web Services

"Newcomer, Eric" wrote:
> 
> Paul,
> 
> Ok, I think we are sort of getting somewhere here.
> 
> -- The Expedia example is not a Web service since it still involves 
> human interaction.  What we want is Expedia to automatically book 
> flights based on calendar choices in a PDA.  

Right now, today, I could build the app that you
describe. Machine reads PDA. Machine interacts with website. It would
take a few days. The problem is that today's service is designed to
interact with people, not machines, so they may change their HTML for
better usability and it would break my program. Four years ago it was
understood that XML would fix this problem but over time it has become
"common wisdom" that problems would not be solved the web way but rather
in the manner they were solved in pre-Web systems.

> Expedia needs to become a "service" to which one can send messages 
> across the Web, not a site that simply serves pages.  

Expedia *is* a service. (else, what is it?)

I *do* send messages to it across the Web. (else how am I talking to
it?)

I communicate with the service by sending and retrieving representations
of information objects ("representational state transfer"). We call
those "pages" because we are thinking about browsers. If those "pages"
are XML documents then they are very machine parsable. If we went as far
as to use RDF then many possibilities open up with respect to
subclassing, inferencing, etc.

If you think that there is some problem that this model is not rich
enough to solve then the burden of proof is on you. But the number of
complicated, diverse applications on the existing Web suggests to me
that you will have a difficult time.

> Would you argue that the Web services APIs that Google and 
> Amazon.com have recently developed and published are not useful 
> since they expose a different paradigm than interacting with 
> those sites via URI based method names and parameters?

Useful? Yes. As useful as they could have been? No.

I thought by now it was common wisdom that Google's service was done in
a manner that was less useful than it could be if they had followed REST
principles. That was the impetus for the addition of the WebMethods
feature. The current SOAP draft explicitly deprecates that usage. 

The reasons for that are described here:

 * http://www.xml.com/pub/a/2002/04/24/google.html

 and here:

 * http://www.w3.org/TR/soap12-part0/#L3677

Amazon chose to have has a REST/HTTP interface which is a feature
superset of their SOAP/RPC interface. Similarly, the current SOAP draft
explicitly deprecates Amazon's SOAP RPC interface. To bring their REST
interface into compliance with the SOAP 1.2 spec they would just have to
wrap their existing XML elements in <soap:Envelope> and <soap:Body>.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Monday, 22 July 2002 12:18:51 UTC