On 04/01/2009, at 12:24 AM, Noah Slater wrote:
You lost me with this. Are we still talking about CouchDB here or
are we on an
(interesting but unrelated) tangent?
A tangent, but the issue does impact Couch ...
What has the limit of query strings to do
with the decision to use POST vs. GET? Are you talking about the
situation where
you want to pass in data to a GET request that would be too long (in
practice,
the RFC doesn't specify a limit) for a query string? My rule of
thumb would be
that if you find your self in that situation, you're doing something
that could
probably be simplified.
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.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Borrow money from pessimists - they don't expect it back.
-- Steven Wright
