Should `etag` be included in resource schemas?

[hudlow]

Since the ETag header doesn't help to provide etags for resources in a list operation, and a client might want to list resources and then cache them or update them with optimistic locking, it might be worthwhile to allow or even recommend or require that resources with etags include them in their schemas.

[gibson042]

ETags are representation-specific unless explicitly marked as weak, which means that they must vary by presence vs. absence of compression/whitespace/etc. (for example, the extra level of indentation from pretty-printing a collection would be enough to invalidate one).

I'm a big fan of including version and documenting how ETags are derived from it, though... at my last gig we adopted an approach whereby they were a concatenation of version and a leading-# representation-specific suffix, and operations could ignore the suffix as appropriate (e.g., behavior of a structured Update may depend upon request Content-Type but not on details of the client's resource representation).

[dv-stewarts]

I've been having this discussion internally at DoubleVerify. There is another open issue, #241, which aims to update the guidance on ETag and is tagged for inclusion in milestone 0.1.

Do you think we can conclude on this discussion and fold the recommendation into the 0.1 milestone updates?

From our perspective, we're trending towards including the ETag in the resource schema if it can be returned as a header. This keeps ETags opaque while also avoiding having to make an additional GET or HEAD request after a listing only to get the ETag prior to updating. This isn't as "pure", but is probably more convenient.

[toumorokoshi]

We will formally update the aeps soon on this, but in a weekly we agreed that it can be part of the resource schema, but must be output only and not be used for verifying resource state. 2025年2月27日(木) 7:27 dv-stewarts ***@***.***>:

…

I've been having this discussion internally at DoubleVerify. There is another open issue, #241 <#241>, which aims to update the guidance on ETag and is tagged for inclusion in milestone 0.1. Do you think we can conclude on this discussion and fold the recommendation into the 0.1 milestone updates? From our perspective, we're trending towards including the ETag in the resource schema if it can be returned as a header. This keeps ETags opaque while also avoiding having to make an additional GET or HEAD request after a listing only to get the ETag prior to updating. This isn't as "pure", but is probably more convenient. — Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC7QSBD7LJOYBHJRDP77VD2R4VFNAVCNFSM6AAAAABYADWJH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGI4TMNRYG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: dv-stewarts]*dv-stewarts* left a comment (aep-dev/aeps#95) <#95 (comment)> I've been having this discussion internally at DoubleVerify. There is another open issue, #241 <#241>, which aims to update the guidance on ETag and is tagged for inclusion in milestone 0.1. Do you think we can conclude on this discussion and fold the recommendation into the 0.1 milestone updates? From our perspective, we're trending towards including the ETag in the resource schema if it can be returned as a header. This keeps ETags opaque while also avoiding having to make an additional GET or HEAD request after a listing only to get the ETag prior to updating. This isn't as "pure", but is probably more convenient. — Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC7QSBD7LJOYBHJRDP77VD2R4VFNAVCNFSM6AAAAABYADWJH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGI4TMNRYG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>