我们正在构建我们使用的 REST APIETag https://en.wikipedia.org/wiki/HTTP_ETag有两种用途：
- 通过允许客户端避免重新加载资源来节省带宽（对我们来说并不重要）
- 解决并发问题（丢失更新问题)
从实际角度来看，我想知道用什么来计算 ETag。
-
项目哈希值
我们使用响应中发送的项目对象（的 json 转储）的哈希值。这很好用。检查 PUT 请求很容易：从数据库中提取项目、计算哈希值、比较。然而，它使得关注点分离有点“泄漏”：构建项目响应的层与负责 ETag 计算的层是交错的。此外，附加数据（响应标头）可能很重要，如果确实如此，仅仅因为项目本身没有更改而标头发生更改而发送 304 可能是不合适的。
-
响应哈希
另一种方法是在发送响应之前对响应进行哈希处理。这样做可以使 ETag 层的计算部分更加清晰。但是，在 PUT 请求中，我们不能只是从数据库中提取项目来检查 ETag，因为我们没有额外的数据。
第一种方法（计算项哈希）似乎适合情况 2 并发问题。第二种方法（计算有效负载哈希，包括元数据、标头）适用于情况 1，节省带宽。
将响应的每一位（包括标头）放入请求中似乎是正确的，因为其中的每个更改都可能是相关的，并且需要客户端刷新其缓存。但我不知道如何使用这样的 ETag 管理 PUT 或 DELETE 请求的并发性。
从实际角度来看，我们应该使用项目哈希还是响应哈希，以及如何使用其中一种来处理这两种情况？
根据您的描述，我认为响应哈希是这里唯一有意义的哈希。
首先，为了使用条件请求来避免更新丢失问题，验证器需要坚强 https://datatracker.ietf.org/doc/html/rfc7232#section-3.1.
源服务器必须在以下情况下使用强比较功能：
比较 If-Match 的实体标签（第 2.3.2 节），因为客户端
旨在此先决条件阻止应用该方法，如果
表示数据有任何更改。
仅当表示形式逐位相同时，强验证器才能具有相同的值。但是，如果正如您所说，“附加数据可能很重要”超出了项目哈希值，那么您就无法决定一个强大的ETag当时。因此，在这种情况下，您根本无法进行项目哈希并与规范保持一致。
当然，您可以决定附加数据not没关系，在这种情况下，您仍然可以进行项目哈希并与规范保持一致。但这消除了您为响应哈希想法给出的一个缺点（“我们不能只是从数据库中提取项目来检查 ETag，因为我们没有额外的数据”）。
换句话说：你需要一个强大的ETag以避免丢失更新和强大的验证器必须改变 https://datatracker.ietf.org/doc/html/rfc7232#section-2.1“每当表示数据发生变化时，可以在 GET 的 200（OK）响应的有效负载主体中观察到。”所以要构建ETag你必须知道你所知道的一切才能回应GET无论如何，因此在响应层中执行此操作没有任何缺点。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
