A first-pass fix to this is to calculate a checksum of the object contents and use that as the ETag. This does cause some extra overhead for requests that are not sent back to the client but a larger change would be needed to correctly represent the internal changes in object states.

There is a problem by using only GET requests to calculate the hash: the ETag returned from a PATCH will not be the one that would be returned from a GET on the same resource.

Decided to not do a partial fix and properly track object versions in a later release.

A solution to the PATCH/POST problem would of course be to perform a fake GET request and use that as the hash. This would slow down modifying requests but in theory it would also allow the API to return the created and/or updated element in question.

The problem with all of these is the fact that the statistics can be updated constantly making PATCH request effectively impossible to do on live systems that are in use. This would mean that the current implementation is in fact the most reasonable solution at this point and the problem is only on the client side using cached results and expecting statistics to be updated. Whether this is the behavior that all clients exhibit is something that is not known at this point in time.

After thinking about the problem for quite a bit, I've come to the conclusion that this should not be implemented at all and that the ETag documentation must be updated to describe that it only changes if a request done via the REST API modifies a resource.