If-Match revision

[Aurélien Bénel <au...@utt.fr>]

Hi everyone,

I was reading RFC 2616 again, and I noticed the existence of the "If-Match" header.
It seems to be the appropriate HTTP way to handle revision conflict detection on both PUT and DELETE. 

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?


Regards,

Aurélien

Re: If-Match revision

[Paul Davis <pa...@gmail.com>]

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 <au...@utt.fr> 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?
>
>

Re: If-Match revision

[Aurélien Bénel <au...@utt.fr>]

>> 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?

Re: If-Match revision

[Robert Newson <rn...@apache.org>]

CouchDB has supported If-Match for years.

B.

On 18 April 2012 13:02, Aurélien Bénel <au...@utt.fr> wrote:
> Hi everyone,
>
> I was reading RFC 2616 again, and I noticed the existence of the "If-Match" header.
> It seems to be the appropriate HTTP way to handle revision conflict detection on both PUT and DELETE.
>
> 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?
>
>
> Regards,
>
> Aurélien
>
>