QUERY

> I suppose thedecision as to whether QUERY should be introduced or GET
> expended depends on how much they will share.

I'm not a big fan of a new method for submitting complex queries, nor
even extending GET to support a body if that body is in any way used to
change the meaning of the URI(*).  A query really should be identifiable
by a URI.  IMHO, if urlencoded syntax is insufficiently expressive for
some particular query then you could do this;

POST /query HTTP/1.1
Host: example.org
Content-Type; application/x-complex-query

[query goes here]

which would return;

HTTP/1.1 201 Created
Location: http://example.org/queries/12371232

A GET on that URI would return the query results.

I do see *some* value to a new method that is side-effect free and
carries a body, but I don't see it being used for queries.  I see it
being used for things like converting a document from one format to
another.  However, I don't see enough value in this over POST to justify
going to the effort of deploying it.

(*) I would consider using a body on GET iff it were used as a header,
such as if a SOAP envelope (minus the body - note to self, suggest to
XMLP to remove requirement for at least one body element) were there.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Wednesday, 30 January 2002 12:49:50 UTC