REST API - 使用 ETag 进行并发检查答案

【问题标题】：REST API - Concurrency Check Using ETagsREST API - 使用 ETag 进行并发检查
【发布时间】：2020-09-11 07:21:29
【问题描述】：

在构建 RESTful api 时，解决并发问题的一种方法是使用 ETag。为此，客户端必须在请求标头中指定 ETag。

如果请求标头中不存在 ETag，一般做法是什么？我们只返回一个 BadRequest 吗？我们是否还在响应中包含 ETag 的缺失以通知客户？是否有任何方法可以通知客户端需要特定标头的操作？

提前致谢？

【问题讨论】：

标签： c# rest asp.net-core-webapi

【解决方案1】：

Wikipedia 在 ETag 上所说的内容：

ETag 是一个不透明的标识符，由 Web 服务器分配，用于在 URL 中找到的特定版本的资源。如果该 URL 上的资源表示发生变化，则会分配一个新的不同的 ETag。

然后

如果该 URL 上的资源表示发生变化，则会分配一个新的不同的 ETag

话虽如此，应该清楚的是，在 GET 请求中，不应该出现 ETag，或者它不应该被 Web 服务器考虑。
但是，对GET 请求的响应应该包含ETag，它应该用于下一个实体的修改。

其实如果涉及缓存的话，可以按照MDN在GET请求中呈现，但是从你的问题中我可以看出，这里不是这样吗？

Here 你可以阅读ETag 在 Azure 表存储中的使用方式。请注意，ATS 允许省略 ETag。在这种情况下，将执行普通更新。这是有道理的：允许省略 ETag 意味着更大的灵活性；程序员可以决定在哪里处理并发——通过 Azure 表存储（使用 ETag）或在客户端级别，调用方检查（或至少应该 odso）请求不会遇到并发问题。

说到你的 RESTful api，这意味着没有通用的做法。您应该决定客户端是否能够在没有Etag 的情况下使用您的 API，如果不能，则返回适当的错误代码。要通知客户端应该使用ETags，您可以将它们与响应一起返回。

【讨论】：

【解决方案2】：

如果请求标头中不存在 ETag，一般做法是什么？我们只返回一个 BadRequest 吗？

RFC 6586 定义 428 Precondition Required:

The 428 status code indicates that the origin server 
requires the request to be conditional.

我们是否还在响应中包含不存在 ETag 以通知客户？

是的，就像您对任何其他 client error in HTTP 所做的那样。

Except when responding to a HEAD request, the server 
SHOULD send a representation containing an explanation 
of the error situation, and whether it is a temporary 
or permanent condition.

RFC 6585 包含此示例

<html>
  <head>
     <title>Precondition Required</title>
  </head>
  <body>
     <h1>Precondition Required</h1>
     <p>This request is required to be conditional;
     try using "If-Match".</p>
  </body>
</html>

是否有任何方法可以通知客户端需要特定标头的操作？

我没有看到任何标准机制可以将此信息传递给通用组件。

我相信，通常的机制会传达该信息以响应 OPTIONS 请求：

生成对 OPTIONS 的成功响应的服务器应该发送任何可能指示服务器实现并适用于目标资源的可选功能的标头字段（例如，允许），包括本规范未定义的潜在扩展。响应负载（如果有）也可能以机器或人类可读的表示形式描述通信选项。

【讨论】：