On 3 Jan 2009, at 13:12, Noah Slater wrote:
On Fri, Jan 02, 2009 at 04:52:29PM -0800, Chris Anderson wrote:
In the normal case you would POST a document to a collection when you
want the server to choose the final URL. However, intermediaries have
a habit of retrying POSTs randomly, so when you POST and id-less
Couch
document, occasionally duplicate documents are created. We work
around
this by recommending PUT as the document creation method. Of course
clients can specify any document id they'd like to, but for
lightweight clients CouchDB provides the _uuids service.
The POST is pragmatic for cache-control reasons, but also RESTy,
because it exposes the service that CouchDB uses internally for
directing document POSTs to new ids. By using the _uuids service,
clients can become the part of CouchDB that would direct documents to
URLs in a collection.
I don't agree and I think it should change to GET.
* You hint that it is to mirror the process required for the
creation of
documents. This is not how we should be designing the interface.
UUID
creation is totally disjoint and should be considered separately.
* You mention cache-control, but nothing about GET semantics implies
cacheability so unless there is some major flaw with common UA
implementations I don't see this as a valid argument.
After researching this in more depth it turns out I was indeed
mistaken in thinking *any* responses to GET requests can potentially
be cached. Quoting from RFC 2616 [1]:
"The response to a GET request is cacheable if and only if it meets
the requirements for HTTP caching described in section 13."
And section 13 [2] goes on to say that operations are transparent by
default, and transparency can be relaxed:
- only by an explicit protocol-level request when relaxed by
client or origin server
- only with an explicit warning to the end user when relaxed by
cache or client
So as you say, unless common implementations have flaws, I think GET
responses would not be cached unless we explicitly say so, assuming we
handle the HEAD + If-Modified-Since etc. requests correctly (which is
what a conforming cache proxy should do).
[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
[2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
Jason
--
Jason Davies
www.jasondavies.com
