On 05/11/2008, at 9:28 AM, Chris Anderson wrote:
On Tue, Nov 4, 2008 at 2:41 PM, Kore Nordmann <[EMAIL PROTECTED]
nordmann.de> wrote:
I would actually prefer using GET with a request body for fetching
view
results with multiple keys, since otherwise the semantics [1] of POST
requests are violated.
I agree, GET would be nice. Perhaps we should support GET (via url
params) as well as POST.
Starting with using the HTTP methods in a
different meaning then they have been developed for, just because of
potential implementation details, may open a can of worms, breaking
the
whole HTTP standard.
I don't think the situation is as dire as this. There's an argument
that because multi-key view requests are in effect asking the server
to do a lot of processing, POST is appropriate. GET is suitable only
if we're willing to accept limitations the number of keys (remember, a
single key can be arbitrarily long) based on practical URL length
limitations.
I guess I'm not a big believer in the cacheability of requests that
include bodies, regardless of verb. It seems that the best argument
for GET is cacheablity. I would fully support a patch to extract a
JSON array of keys from the URL for view GET requests.
I think we should keep POST available, because there are people who
will need to make requests for more keys than URL parameters can
handle.
One solution would be to separate the specification of the key set
from the document retrieval operation.
e.g.
client POST the keys -> return a UUID for a 'key set'
server would cache these for some amount of time, and might return the
same id to different POSTs of the same key set.
client GET documents with the key set as a parameter.
Thus you get cacheable multiple-document requests without breaking
HTTP semantics or running into the URL length restriction.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Plurality is not to be assumed without necessity
-- William of Ockham (ca. 1285-1349)
