couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: [PATCH] Views: Multiple keys
Date Tue, 04 Nov 2008 23:45:57 GMT

On 05/11/2008, at 9:28 AM, Chris Anderson wrote:

> On Tue, Nov 4, 2008 at 2:41 PM, Kore Nordmann <mail@kore- 
>> 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.


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)

View raw message