Reputation: 1824
I understand the use of etags for optimistic concurrency control (e.g. in a RESTful style of architecture), and I've read that etags should be different for different representations of the same resource. Why is that?
Ultimately aren't we interested in knowing if the resource has changed so we can handle concurrent modifications? I'm having a hard time even envisioning when a resource's representation would change without the resource itself changing, so I'm obviously missing some basic understanding.
Upvotes: 16
Views: 1977
Reputation: 996
This is not a matter of debate when you lay out facts or when you read the HTTP&HTTPbis spec.
ETag is a means of caching and concurrency control. Weak ETags is only a means of poor-man's caching.
In terms of caching (GET) - uri + content-type + etag can help you save bandwidth by not responding with the payload as well, but just with 304 status code.
In terms of concurrency control (POST;PUT;PATCH) - it is impetuous to have the ETag calculated based on URI + content-type + bit-exact response payload. Why?
Conditional requests should be treated with a semantic similar to "Given that my view of the world is still the same, then perform the request. Fail otherwise". My view of the world is made out of a past response (URI + headers + payload).
Upvotes: 5
Reputation: 4618
Good question, and I think it's a matter of some debate.
I think that most would say that the ETag represents not only the resource version, but also the content type. This would make sense for caching responses based on content type, language, etc.
Check out the following links:
Upvotes: 10