Re: [Specifications] Question about resource versioning (#190)

@angelo-v Let's say I have a collection: `c=[i1,i2,i3,...]` and the first item looks something like this: `i1 = {someProperty: "x"}`. Each item has a PUT link and has a separate etag than the collection itself. The first item has an etag: "a". While I figure out what text to choose to override the "x" value, somebody does the exact same thing and sets "someProperty" to "y". Because of this the etag of the first item changes to "b". I decided to instead of overriding "x" I rather append it with "z", so I send a PUT request with "xz" based on the "a" etag, when the resource already has the "b" etag. This is obviously a conflict which we normally avoid by send the "a" etag along with the PUT request. Now let's check the proposed solutions:

 1. "Just PUT without etag and accept to override"
    The API will override "someProperty" to "xz" and "y" is lost. Nobody will know that there was a conflict, so they won't be able to solve it and for example set our property to "yz".
 2. "Make a GET or OPTION request before PUTting, to get the etag."
    - If you meant that I should send a GET or OPTION request just to get the etag for my PUT request, then that means almost the same as the first solution, because in that case I will still send "xz" but with the "b" etag, which is a lie, because it is based on the "a" etag.
    - By the GET there is another option. I don't add the PUT link when I send back the representation of the collection, and I send an additional request for each item just to get that PUT link with the etag. That is suboptimal because I need 2 HTTP requests and it makes the client code more complicated, because I might get back "x" in my first request and "y" with etag "b" in my second request. Now I have to compare the returned values, probably replace "x", etc.

What if I have a bulk update PUT link I can use to update arbitrary numbers of items in the collection? If I want to update a dozen items at once, then that is 12 additonal HTTP requests. Another issue here that I have to send 12 etags somehow with the request. So not just the response, but the request headers should carry multiple etags, which it is not capable of.

I think it is obvious that the design of the ETag headers is broken and we have to send that info in the message body rather than in these headers...

-- 
GitHub Notification of comment by inf3rno
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/190#issuecomment-484624560 using your GitHub account

Received on Thursday, 18 April 2019 18:17:16 UTC