On Tue, Nov 4, 2008 at 2:41 PM, Kore Nordmann <[EMAIL PROTECTED]> 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. Chris -- Chris Anderson http://jchris.mfdz.com
