为REST计算ETag

Question

我们正在构建REST，其中我们将ETag用于两种用途：

1. 通过允许客户端避免重新加载资源来节省带宽(对我们来说并不重要)
2. 解决并发问题(更新丢失问题)

从实际的角度来看，我想知道如何计算ETag。

• 项散列 我们使用响应中发送的(json转储) item对象的散列。这个很好用。检查PUT请求很容易:从DB中提取条目，计算哈希，进行比较。然而，它使关注点的分离有点“泄漏”：从项构建响应的层与负责ETag计算的层交织在一起。此外，额外的数据(响应头)可能很重要，如果是这样的话，仅仅因为条目本身没有改变就发送304，而标头本身可能不合适。
• 响应散列 另一种方法是在发送响应之前先散列响应。这样做可以使计算部分的ETag层更加清晰。但是，对于PUT请求，我们不能仅仅从DB中提取项来检查ETag，因为我们没有额外的数据。

第一种方法(计算项哈希)似乎适用于案例2的并发问题。第二种方法(计算有效负载散列，包括元数据、标头)将适合于情况1节省带宽。

在请求中放置每个响应(包括头)似乎是正确的，因为那里的每一个更改都可能是相关的，并要求客户机刷新其缓存。但是我不知道如何管理使用这样一个ETag的PUT或DELETE请求的并发性。

从实际的角度来看，我们应该使用项散列还是响应散列，如何使用其中之一来处理这两种情况？

Answer 1

考虑到您的描述，我认为响应散列是这里唯一有意义的。

首先，为了使用条件请求来避免丢失的更新问题，验证器需要坚强。

在比较If-Match的实体标记时，源服务器必须使用强比较函数(第2.3.2节)，因为客户端打算在表示数据发生任何更改时阻止应用该方法。

强验证器只能在表示为位对位相同时才具有相同的值。但是，如果，正如您所说的，“额外的数据可能会影响”项哈希之外的内容，那么此时您就无法决定一个强大的ETag。因此，在这种情况下，您根本无法执行项哈希操作并与规范保持一致。

当然，您可以决定附加数据并不重要，在这种情况下，您仍然可以进行项哈希，并与规范保持一致。但是，这消除了响应散列的一个缺点(“我们不能从DB中提取项来检查ETag，因为我们没有额外的数据”)。

换句话说:您需要一个强ETag来避免丢失的更新，而强验证器必须改变“每当发生对表示数据的更改时，就需要在200 (OK)响应的有效负载体中观察到要获取的数据”。因此，要构建ETag，您必须知道在任何情况下响应GET所知道的一切，所以在响应层中这样做没有坏处。