The thing about If-Match is that its not necessarily a way to specify a value for the action. IOW, its a conditional for the request, but is not the most elegant thing for specifying a revision to act upon. Since we have sub paths to documents its hard to cleanly specify the revision as a URL path component as well. Which basically leaves us with the query string.
Granted we could switch it to path variables which is probably the most elegant but client support for that is non existent. On Wed, Apr 18, 2012 at 9:34 AM, Aurélien Bénel <[email protected]> wrote: >>> I was reading RFC 2616 again, and I noticed the existence of the "If-Match" >>> header. (...) Do you remember what was the design rationale for not using >>> it to pass revision IDs to CouchDB? Are there any limitations with this >>> header definition? >> CouchDB has supported If-Match for years. > > Thanks for your answer Robert. > > Don't take my question as a rebuke. I'm just interested in REST > architectures, I love CouchDB, and I wanted to know if there was a problem > with the definition of "If-Match". > > I'm happy to read it is already implemented*, but I wonder why this is not > presented as the default way to pass revisions to CouchDB. Is it just a > historical reason? Or is the other way considered to be better? > > > Regards, > > Aurélien > > [*] On the API wiki, the feature is documented for DELETE but not for PUT. > Should I add it? > >
