On 3 Jan 2009, at 14:41, Jason Davies wrote:
On 3 Jan 2009, at 14:17, Antony Blakey wrote:
The multikey get in Couch should be a GET, but it can't be unless
you want you API to be limited by the (practical) limitation on URL
length.
From an API perspective, I think POST and GET mix up idempotency
with the ability to have a payload or not, which in practical terms
results in people using POST when they should use GET, because
those two issues, whilst theoretically orthogonal, and not
implemented that way.
Continuing the tangent...
Someone should invent an extension to HTTP whereby a client may
issue multiple GET requests at once at the beginning of a single TCP
connection. These resources may take time to generate, but are
amenable to parallelisation of some kind thus making it advantageous
to do this. This is a bit like KeepAlive, except that you can
request e.g. multiple CouchDB keys right at the beginning for
maximum performance, rather than serially.
This is where I hope someone will pipe up and say this already
exists :-)
Aha, http://en.wikipedia.org/wiki/HTTP_pipelining is what I am
thinking of.
Although it kind of works as a potential alternative to the multikey
POST, it won't return rows in any particular order, where as the
current multikey POST returns rows in the same order as the keys
specified. There will also be slightly more overhead in doing
pipelining, as each request would have to be handled separately on the
server-side. In any case, most Web browsers either don't support
pipelining or they have it turned off by default, so writing AJAX apps
using this would be a no-no.
As CouchDB is HTTP/1.1-compliant, it should support pipelining out-of-
the-box.
Jason
--
Jason Davies
www.jasondavies.com
