Anne van Kesteren wrote:
> On Fri, 25 Jan 2008 20:30:56 +0100, Close, Tyler J.
> <[EMAIL PROTECTED]>
> wrote:
> > In Amazon's SimpleDB API, the request URL contains a cryptographic
> > signature of the request arguments. See:
> >
> >
> http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/De
> veloperGuide/REST_RESTAuth.html
> >
> > The WG's current proposal doubles the cost of using the
> Amazon SimpleDB
> > API in a mashup.
>
> It does not. Per
> http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/De
> veloperGuide/MakingRESTRequests.html
> they use GET requests (mostly) which do not cause an
> additional request to
> be issued.
Ah, I didn't realize that.
Well, imagine a SimpleDB-like service that didn't abuse GET in this way; say it
used the ATOM publishing protocol. In this case, each unit of information has
its own URI and is mutated using a non-GET operation. When updating a
collection of items, the network round-trips would be doubled by the WG's
current proposal, since the application is doing multiple non-GET operations on
distinct URIs. Surely we don't want to encourage the abuse of GET to avoid this
performance penalty. The WG's current proposal also results in a tragically
humourous network protocol where the server tells the client to PUT to a URL
and then the client asks if it is allowed to PUT to that same URL, and repeats
this question for every URL it receives from the server.
Ian Hickson wrote:
> On Thu, 24 Jan 2008, Close, Tyler J. wrote:
> > I dispute your implied argument that it should be up to me
> to disprove
> > this assumption, rather than up to you to substantiate it,
> but I'll list
> > some plausible use-cases anyways.
>
> I don't see how I could prove the lack of something.
I also repeat my contention that it shouldn't be up to me to disprove the WG's
assumptions. Rather the WG has to convince developers of its assumptions. You
can't just say that because your assumption is a negative you are freed from
the burden of validating it. That's a rather dubious rhetorical trick.
--Tyler
