Provide ETag in record PUT and PATCH responses

[leplatrem]

Since ETags are supposed to be opaque, they are not supposed to be built by the client.

That means when a PUT or a PATCH is performed, the client should be able to update its local ETag for the record without having to inspect the updated last_modified data field.

I therefore suggest to add the ETag header in PUT and PATCH responses, and not only in GET.

[Natim]

👍

[almet]

this works for PUT and PATCH, we should make sure we don't do it for POST, because it can trick the clients into thinking the Etag is for the resource being posted.

[almet]

Copying from my previous comment:

First-hand, it seems weird to have these Etags returned on something else than GETs, because it can be understood that it applies to the resource that was queried. For intance, if you do a POST on /records and that an Etag is returned. Is it supposed to be matched against /records or /records/{id}.

[Natim]

I don't really understand the benefit of having this for PUT and PATCH.

When do we need ETags?

We need ETags to keep tracks of the last time we've sync-ed to be able to resync.

Only a collection_get should enable the client to update the ETag.

When we are doing a POST/PUT/PATCH/DELETE we are updating the collection timestamp (so we are updated the ETag)

I can understand the idea of ETags for the GET record because it is a value we can use to check if the record was updated.

But what would be the benefit of having it for POST/PUT/PATCH/DELETE? Would it be to update the record ETag value? In that case why should we bother to have it stored in the record inside the last_modified field?

[almet]

Getting an Etag allows to keep track of the last revision we know. Returning it on PUT / PATCH would help using the http cache mechanism even for records that were just PUT / PATCHed.

[leplatrem]

Getting an Etag allows to keep track of the last revision we know.
Returning it on PUT / PATCH would help using the http cache mechanism even
for records that were just PUT / PATCHed.

Exactly. Suppose a client has no permission to reach the collection
endpoint, it is obliged to perform an extra GET to obtain the record Etag
that was just updated.
(Since Etags are opaque, client is not supposed to use the last_modified
field value)

As for POST, I haven't thought about it, and would agree to follow your
strategy :)