为什么同一资源的不同表示有不同的 Etag？
我了解使用 etag 进行乐观并发控制（例如，在 RESTful 风格的架构中），并且我读到 etag 对于同一资源的不同表示应该是不同的。这是为什么？
最终，我们是否不想知道资源是否已更改，以便我们可以处理并发修改？我什至很难想象资源的表示何时会在资源本身不发生变化的情况下发生变化，所以我显然缺少一些基本的理解。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题，我认为这是一个值得争论的问题。
我想大多数人会说ETag不仅代表资源版本，还代表内容类型。这对于根据内容类型、语言等缓存响应是有意义的。
请查看以下链接：
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:
当您阐述事实或阅读 HTTP&HTTPbis 规范时，这不是一个争论的问题。
ETag 是一种缓存和并发控制的手段。
弱 ETag 只是穷人缓存的一种手段。
在缓存 (GET) 方面 - uri + content-type + etag 可以帮助您节省带宽，方法是不响应有效负载，而仅响应 304 状态代码。
就并发控制（POST；PUT；PATCH）而言 - 根据 URI + 内容类型 + 位精确的响应负载计算 ETag 是浮躁的。为什么？
条件请求应使用类似于“鉴于我的世界观仍然相同，则执行请求。否则失败”的语义来处理。我的世界观是由过去的响应（URI + 标头 + 有效负载）构成的。
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).