rest - 为什么同一资源的不同表示形式使用不同的 Etag？

Question

我了解 etags 用于乐观并发控制（例如，在 RESTful 架构风格中），并且我读过 etags 对于同一资源的不同表示应该是不同的。这是为什么？

最终，我们难道不是有兴趣知道资源是否已更改，以便我们可以处理并发修改吗？我什至很难想象资源的表示何时会发生变化而资源本身不会发生变化，所以我显然缺少一些基本的理解。

Answer 1

好问题，我认为这是一个有争议的问题。

我想大多数人会说 ETag 不仅代表资源版本，还代表内容类型。这对于基于内容类型、语言等缓存响应是有意义的。

查看以下链接：

• 维基百科关于强与弱 ETag 的文章部分：http ://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation
• 关于内容编码和 ETags 的信息性讨论：http ://www.gossamer-threads.com/lists/apache/dev/339577

Answer 2

当您列出事实或阅读 HTTP&HTTPbis 规范时，这不是一个争论的问题。

ETag 是一种缓存和并发控制的手段。弱 ETags 只是穷人缓存的一种手段。

在缓存 (GET) 方面 - uri + content-type + etag 也可以通过不响应有效负载而仅响应 304 状态代码来帮助您节省带宽。

在并发控制（POST;PUT;PATCH）方面 - 根据 URI + 内容类型 + 位精确响应有效负载计算 ETag 是浮躁的。为什么？

• 如果您基于整个对象计算 ETag，即响应负载的超集（即您的负载给出 a+b，但对象实际上是 a+b+c），那么例如执行 PATCH 最终会失败，因为ETag 改变了……你刷新了……你得到了相同的数据，但 ETag 不同……你用新的 ETag 重试了 PATCH，现在它可以工作了。失败
• 如果您根据有效负载的子集计算 ETag，您实际上是在完全不透明地迫使用户无法控制不安全调用的条件。即使与该 ETag 关联的数据已更改，PATCH 也会成功，这显然不是 HTTP 请求的预期方式。失败

条件请求应该使用类似于“鉴于我的世界观仍然相同，然后执行请求。否则失败”的语义来处理。我对世界的看法是由过去的响应（URI + 标头 + 有效负载）构成的。