HTTP 状态 412(前提条件失败)和数据库版本控制

Question

我正在实现一个访问数据库的 RESTful Web 服务。数据库中的实体版本化以检测多个更新。例如，如果当前值为 {"name":"Bill", "comment":"tinker", "version":3}，如果一个用户 PUT {"name":"Bill", "comment":"tailor", "version":3}，请求成功(200 OK)，新值将是{"name":"Bill", “评论”:“定制”，“版本”:4}。如果第二个用户 PUT {"name":"Bill", "comment":"sailor", "version":3"} 该请求将失败(409 冲突)，因为版本号没有匹配。

存在现有的非 RESTful 接口(interface)，因此无法更改数据库的设计。 RESTful 接口(interface)调用一个现有的接口(interface)来处理检查版本的细节。

RESTful 网络服务的经验法则是尽可能遵循 HTTP 的细节。在这种情况下，在请求中使用条件 header 并在版本不匹配时返回 412 Precondition Failed 会更好吗？相应的 header 似乎是 If-Match。此 header 采用 ETag(实体标签)，它可以是资源当前状态表示的哈希值。

如果我这样做，ETag 只是为了表现，因为该版本仍然是我要测试的真实版本。

除了“让它更符合 REST 风格”之外，还有什么我应该这样做的理由吗？

Answer 1

如果您使用 HTTP，正确的做法是始终遵循 HTTP 规范，原因很简单，就是让理解规范的人能够正确运行。

412 只应在前提条件(例如 If-Match)导致版本匹配失败时使用，而 409 应在实体会导致冲突时使用 (HTTP 规范本身在 definition of 409 中暗示了这种行为)。

因此，不发送 ETag 的客户端不会期待 412。相反，发送 ETag 的客户端不会理解是 ETag 导致了 409。

我会坚持一种方式。你说“数据库模式不能改变”，但这并不能阻止你(就在 HTTP 服务器层)从数据库表示中提取版本并将其放入 ETag，然后在途中，获取 If-Match header 并将其放回版本字段中。

但并不禁止完全在实体主体中执行此操作。它只需要您解释概念及其工作原理，而使用 ETag 解决方案，您只需将人们指向 HTTP 规范。

编辑:版本标志不必是当前资源的散列；一个版本是完全可以接受的。 ETag: "3" 是一个完全有效的 ETag。