if-match HTTP头是否需要两阶段提交？

我正试图设计一个RESTfulWebAPI，所以我一直在学习。我喜欢使用etag实现乐观并发的想法，并试图用它来创建一种安全的方式，在没有竞争条件的情况下添加资源。然而，我注意到以下两种说法：

如果在没有If Match header字段的情况下，请求将导致除2xx或412状态以外的任何其他状态，则必须忽略If Match header

用于更新资源（例如，PUT）的请求可包括If-Match报头字段，以指示如果与If-Match值（单个实体标记）对应的实体不再是该资源的表示，则不得应用请求方法

我正在使用RDBMS，在尝试之前不知道事务是否会成功提交，所以我认为第一个要求似乎有点繁重。如果有人提供一个<代码> >匹配< < /Cord>头>不匹配的ETAG：如果提交成功，则我应该注意<代码> >匹配< <代码>标题，不要尝试提交，返回412。如果提交失败，那么没有

If Match

头的请求将导致非2XX/412响应，因此我必须忽略

If Match

头，这意味着我应该尝试提交

据我所知，我有两个选择：

在尝试提交之前，使用两阶段提交可以预见提交是否会成功

忽略上面的第一个要求，并返回412，即使忽略

if Match

会导致非2XX/412响应。（这是我倾向的一个）

还有其他想法吗？我是否误解了规范？

像“除非修改否则更新”（乐观锁定）这样的东西不起作用吗？实体需要在数据库中存储版本号或etag

运行不需要提交的验证，忽略etag，必要时返回错误

更新实体，其中id=：the_id和etag=：expected_etag

这将为受影响的行返回0或1

如果0，则资源已看到并发更新（或者id完全错误，您可以单独检查）。在本例中，返回412

承诺

如果提交失败，则根据需要返回错误

---

也许这在理论上有些道理，但根据我目前对HTTP规范的理解，我会将If Match-like头的使用分类为除安全方法外几乎所有方法都无法使用的类型，因为：

“如果在没有If Match header字段的情况下，请求将导致除2xx或412状态以外的任何其他状态，则必须忽略If Match header。”

为什么?？这仅仅是因为在大多数实际情况下，如果请求得到执行，就不可能预见会发生什么

例如，谁能预见到必须运行的代码中出现IO级错误或某些异常情况

---

如果将5xx添加到2xx和412中，它会更“可解决”。

稍微相关，412人群可能会感兴趣：谢谢，我没有考虑将其推到DB中。