Re: Is "GET" or "query" the operation?

Hi Dan,

On Tue, May 24, 2005 at 11:01:16AM +0100, Dan Connolly wrote:
> > My question is, if an HTTP agent invokes GET on the query URI, and
> > receives a successful response as a result, what operation does it 
> know
> > was successfully invoked, "GET", or "query"?
> 
> I don't think I understand the difference.

Well an HTTP message can only have one thing that it's asking to be
done, no?  It seems to me that either the operation is either "GET",
"query", or that the two are semantically equivalent.

>Can you sketch a test case
> that
> we could use to tell the difference?

Actually, after much deliberation, no, because "query" doesn't have any
defined operational semantics in the specification, so I can't test for
them.  Besides, I fully expect that any test I devise will tell us that
GET is the operation being used because it comes along for the ride
whenever you turn URIs into data.  That's my point, really.

> > FWIW, my preference would be that the answer be "GET" and that "query"
> > be described as purely informative, i.e. not part of any contract.
> 
> What would that look like in the spec?

It would mean a pretty significant rewrite of section 2, since the
current assumption made there seems to be that the SPARQL spec defines
the operations (rather than any underlying application protocols), and
those operations have to be somehow bound to the protocol.  I believe
that the SPARQL spec should avoid defining operations, or at least avoid
using them when binding to application protocols.

Also, it would mean rewriting the WSDL to use http:GET as the operation
rather than "query".  Here's some WSDL 2.0 written by Dave Orchard to
describe the Yahoo News services, as an example of this kind of WSDL;

http://www.pacificspirit.com/Authoring/wsdl/YahooV1Search.wsdl

Note though, that I'm not endorsing the use of WSDL at all - I
personally think it's underspecified and ambiguous, and only introduces
confusion, especially in the context of Web based services (i.e. not
"Web services").  I also don't think it helps describe even SOAP/HTTP
based services, which you mentioned you were planning to incorporate
into the spec at a later date.

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Wednesday, 8 June 2005 20:50:06 UTC