Re: URI serialization issues

Hey,

On 1/17/06, Kendall Clark <kendall@monkeyfist.com> wrote:
> 1. GET being 'safe' is always talked about it terms of side effects
> like deleting a resource -- the DOS issue is different.

That's the common use, yes, but the reality of "safe" is a bit more
complicated.  Consider what Roy says here;

http://lists.w3.org/Archives/Public/www-tag/2002Apr/0207

In particular he notes "money, BTW, is considered property for the
sake of this definition", and each fulfilled request for data likely
costs most publishers some amount of money, some more than others. 
But it's up to each publisher to decide which data gets a URI, since
for each one published, a promise is made that the publisher will
absorb those charges.

> 2. How does the query coming in via POST instead of GET really help
> anything? In both cases a service may send QueryRequestRefused in
> response to a request that's too expensive to complete. (I'm cc'ing
> Pat Hayes because he +1'd yr comments and I wanna make sure I know
> what he thinks of this.)

It would help things in the sense that there wouldn't be a URI around
that spiders, pre-fetchers, and other automata might "bombard" with
requests without understanding the cost to the publisher.  POST
doesn't work like that because it entails the client (potentially)
incurring a obligation ... which is why spiders don't use it (that and
the fact that they don't know *what* to POST).

> 3. It's not clear that you can say, statically, in advance, which
> queries against which datasets will be computationally too expensive,
> not least because "cost" may have a load or busyness factor that's
> dynamic. What is my implementation just wants to set a timeout... if
> a query takes longer than 60 seconds, it's too expensive ande I
> return QueryRequestRefused. That seems perfectly reasonable.  But in
> that case I may not be doing any query analysis, and so I don't know
> which queries should be POST and which GET. *Confusing* and I don't
> see the utility.

Right.  There's no hard line here that can be described because each
publisher will be willing to bare different costs.  All that you can
do is describe the tradeoffs.

> So if there's a request that times out over GET, and I had some way
> (how?) to tell the client to submit again via POST, what would be the
> point of that? It will still timeout via POST and I've only wasted
> the client's time and the service's.

Presumably you'd have a greater timeout with POST, or even none at
all, because of the differences between POST and GET as described
above.

Cheers,

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

Received on Wednesday, 18 January 2006 05:18:27 UTC