编辑冲突和 409 与 412 响应 [英] Edit conflicts and 409 vs. 412 responses
问题描述
我们有一个 REST API，用于与应用程序后端配合使用.我们需要实现一个冲突预防功能，它会在编辑请求 (POST/PUT) 时检查记录在客户端上次读取和现在之间是否没有修改，如果是，则会告诉客户端存在冲突.
We have a REST API which is used to work with the application backend. We need to implement a conflict prevention function, which would on edit request (POST/PUT) would check if the record was not modified between the client's last read of it and now, and if it were, would tell the client there's a conflict.
问题是如何发送冲突检查标签(这很可能是一个时间戳，但我们不想强制要求)以及如何返回错误.
The question is how to send the conflict check tag (which most probably would be a timestamp, but we don't want to mandate that) and how to return the error.
我们希望尽可能多地使用标准的 REST 模式，因此我们考虑了以下解决方案:
We would like to use standard REST patterns as much as possible, so here the solutions we considered:
使用If-Modified-Since.这里的问题是它要求使用时间戳，并且规范还说您必须返回 412.我们想返回更具体的 409 代码，以表明这是一个编辑冲突，如规范中所述，而不是可能由其他原因引起的更通用的 412.这也将使客户端更容易对编辑冲突进行特殊处理，因为它们会有专用的错误代码.
Using If-Modified-Since. The problem here is that it mandates using a timestamp and also the spec says you MUST return 412. We'd like to return more specific 409 code, to indicate it is an edit conflict, as described in the spec, instead of much more generic 412 which can be caused by other reasons. This would also make it much easier for the client to have special handling for edit conflicts, because they would have dedicated error code.
使用If-Match.更好，因为我们可以使用附加到它的任何数据，但规范再次要求使用 412，即使 409 更适合我们的情况.此外，规范建议 If-Match 与 Etags 相关联，我们不将 Etags 用于我们的数据，因为为每条记录计算适当的 Etag 是不可行的.我们有将用于检查的标记作为记录数据的一部分，但它不是作为 ETag 发送的，并且现有客户端不处理 ETag，因此如果可能，我们不想将这个新要求强加给客户端.
Using If-Match. Better since we can use any data attached to it, but again the spec mandates using 412 even though 409 fits our case better. Also, the spec suggests If-Match is linked to Etags, and we don't use Etags for our data because it's not feasible to calculate proper Etag for every record. We have the tag that we would be using for checks as part of the record data, but it is not sent as ETag and existing clients do not process ETags, so we wouldn't want to impose this new requirement on the clients if possible.
使用自定义 X-Header.这会工作得很好，而且很容易让客户添加，但如果可能，我们更喜欢使用标准的 REST 方式.
Using custom X-Header. This would work just fine and would be pretty easy for the clients to add but we'd prefer using standard REST means if possible.
那么，在这种情况下推荐的方式是什么?有没有办法使用标准的 REST 方式，用 409 响应并让它一切顺利?
So, what is the recommended way in this case? Is there a way to use standard REST means, respond with 409 and have it all nice and clean?
推荐答案
基本上，如果标题中有 If-* 前置条件，则必须返回 412.即使你使用自定义的 X-Header，也只是意味着 header 没有定义它必须返回 412.如果使用自定义标头作为前提条件，则应根据其定义返回412:
Basically, if you have If-* preconditions in the header, you must return 412. Even if you use custom X-Header, it only means that header has no definition where it says it must return 412. If the custom header is used as a precondition, you should return 412 according to its definition:
此响应代码允许客户端对当前资源元信息(头字段数据)设置前提条件...
This response code allows the client to place preconditions on the current resource metainformation (header field data) ...
E-Tag 通常只作为 If-* 前提条件的一部分在请求中发送，所以如果你想要 409 那么你就不会t 使用 E-Tag.
E-Tag is usually only sent in requests as part of If-* preconditions, so if you want 409 then you won't use E-Tag.
如果您想使用409，只需将前置条件或后置条件放在请求正文中，而不是标题中.当条件失败时，WebDav 返回 403 或 409.409 当客户端可能能够修复请求时.参见 RFC 3259.
If you want to use 409, just put the preconditions or postconditions in the request body, not a header. WebDav returns 403 or 409 when a condition fails. 409 when the client might be able to fix the request. See RFC 3259.
所以，总结一下:如果您的先决条件在标题中，请使用 412，否则使用 409.
So, to conclude: Use 412 if your preconditions are in a header, otherwise use 409.
这篇关于编辑冲突和 409 与 412 响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
