RE: Issue 5; GET vs GetLastTradePrice

Mark,

This might be your version of the issue, but I do not think it's the question for Roy.  The question raised on this thread was more general -- the relationship between Web services and REST.   Web services are more abstract than GetLastTradePrice, there is no requirement in SOAP to define services that way.  

I think the most interesting comparison is between document-oriented Web services and REST, not RPC-oriented.  We have to think about what the technology is really good for.  I think Web services are good for integrating disparate software domains.  EAI technology (and B2B technology for that matter) has been used in the past for this purpose.  And these are document-oriented technologies.  

Granted, CORBA has also been used for integrating disparate software domains -- the majority of our customers like Boeing and Credit Suisse First Boston do so -- but there's nothing in CORBA that requires a specific, fine-grained interface.  CORBA's architecture is about as open as Web services.

As Mike said, you can accomplish the same goal many ways.  We could certainly push the entire burden of understanding messages into the applications, and just use primitive file transfer methods to transfer documents.  Many systems work like that; many integration applications in production still use magnetic tapes to move information, and entire programs are written for the specific purpose of transferring file formats from one application to another.

But XML provides us tools to improve upon this most basic of integration scenarios by adding semantic information *of some kind* whether it's a simple service name and associated data or a specific interface.  There is no requirement in Web services for the semantic information to be a specific interface.  But if you have a service name, you can use it as a key to "discover" service description information that can help avoid a lot of custom coding for application integration.  This loosely-coupled model provides many benefits but you keep focusing on the tightly-coupled model.

Unless you have some other use case in mind for Web services?  But if so then the argument needs to focus on that, but then we're back to where we started months if not years ago.  I believe the trouble is now and has always been (I think I've followed your posts for about three years now) that you are assuming one kind of use case while the rest of us are assuming another.

Eric

-----Original Message-----
From: Baker, Mark 
Sent: Wednesday, January 01, 2003 11:44 PM
To: Christopher B Ferris
Cc: fielding@apache.org; www-ws-arch@w3.org
Subject: Issue 5; GET vs GetLastTradePrice



Oops, I'll CC Roy this time.

[Roy, there's a question for you at the end, if you don't mind.
Thanks!]

My resolution for the new year is to not get side-tracked into a
wandering perma-thread.  I'm going to focus solely on the value of URIs
and GET as a superior means of retrieving data, whether a human is
nearby to interpret it or not.

FWIW, this is issue 5[1];

On Tue, Dec 31, 2002 at 04:57:50PM -0500, Christopher B Ferris wrote:
> I don't believe it is moot. I was NOT suggesting that GET is 
> inappropriate.
> The fact is that we added the GET MEP to SOAP1.2 HTTP binding. Again, that 
> wasn't
> the issue to which I was responding. It was the argument that you've been 
> continuing
> to harp upon, that all we need is in REST (and more specifically, that you 
> contend
> that all we need is HTTP).

I contend that there exists solutions to the problems Web services are
trying to solve, that obey all of REST's constraints, thereby inheriting
all of its desirable properties and putting it "on the Web".

Today, for the most part, yes, that means using HTTP.  As you know, I
also like SOAP when used as a protocol extension protocol (to answer
Anne's question), since it adds useful features to HTTP (and other
protocols) that HTTP doesn't have.

> > URIs and GET are a low-coordination-cost way of retrieving data.  There
> > is *NOTHING* human-specific about that.
> 
> Apparently, you missed my point entirely. I wasn't suggesting otherwise. I 
> was stating
> that it is not enough. Retrieving data is one thing. Doing something 
> useful with it
> once obtained is another.

Of course.  But when you are retrieving data, why not use GET?  Why
consciously trade in the low coordination costs in the use of GET for a
higher coordination cost "getFoo()" over POST?

> We are not at the point where our software 
> systems can willy-nilly 
> retrieve data without having a clue what form it might take before it is 
> received.

I disagree.  We've been building systems like this for at least 20
years, since the Internet began.

> REST is based on the premise that the agent receiving the data has but one 
> responsibility;
> to render it for (typically) human consumption.

Let's ask Roy, as Arkin suggested.  Roy?

FWIW, this thread started here;

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/thread.html#262

And the message this is a response to is;

http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0267

Thanks, and happy new year to everyone.

 [1] http://www.w3.org/2002/ws/arch/2/issues/wsa-issues.html#x5

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 2 January 2003 07:45:15 UTC