【发布时间】：2019-01-30 03:49:15
【问题描述】：
我正在尝试在我们的软件中实现一些 PATCH 请求（遵循https://www.rfc-editor.org/rfc/rfc7396）。资源有一些不能修改的字段，所以我想当这些字段出现在 HTTP JSON 请求正文中时返回一些错误状态代码。 400 似乎有点太笼统了（我将它用于验证错误，例如电子邮件格式等）。也许在这种情况下还使用了其他一些状态码？
【问题讨论】：
【发布时间】：2019-01-30 03:49:15
【问题描述】：
有一个代码。 . . 8-)
403 Forbidden
服务器理解请求，但拒绝执行。授权将无济于事，并且不应重复请求。如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该描述原因
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
此外，即使没有凭据问题，403 也是适用的。 这在RFC7231 Section 6.5.3 中有解释：
请求可能因某些原因被禁止 与凭据无关
【讨论】：
-
正如@VoiceOfUnreason 所说，我也觉得 403 更多地用于传达凭据问题。例如，Wkipedia 说“HTTP 403 是 HTTP 服务器与客户端通信的标准 HTTP 状态代码，表明服务器理解请求，但由于与授权相关的某种原因不会满足它”，尽管 IIS 使用的子代码发现在同一个维基百科页面上，我认为实际上支持你的观点。
RFC 7231 section 8.2 状态码 registry，所以这是开始的地方。
这显然是请求的问题；客户可能能够修复的东西，因此 4xx 类的条目是合适的。
405 Method Not Allowed 对于您描述的情况是错误的 - 此资源将接受不同的合并补丁文档，但不是存在的那个。
403 Forbidden 错误，因为它传达了与凭据相关的问题，但您描述的是有效负载问题。
409 Conflict 可能是合理的...
由于与目标资源的当前状态冲突，请求无法完成。
我看不出有任何理由表明冲突不能处于“当前状态”的不可变部分。
但我认为你最好的选择是422 Unprocessable Entity
422（Unprocessable Entity）状态码表示服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400 （错误请求）状态代码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生这种错误情况。
另一个值得考虑的好资源是 HTTP 补丁规范。 RFC 5789 列举了补丁可能失败的许多原因，以及在每种情况下适合使用的代码。您可以自行决定这些区别是否适合您的情况。
也可能有更具体的错误，例如“冲突状态”，可以使用此状态代码发出信号，但更具体的错误通常会更有帮助。
【讨论】：
-
我使用 409 来处理乐观锁异常。 422是合理的，我同意。人们可能会认为，在围绕罗伊菲尔丁的论文进行宗教斗争之后，现在社区已经达成了一些共识。我的意思是，关于像这样基本的事情:) 但也许我“没有以正确的方式做事” :) 我见过的一种解决方案是人们只使用 KISS 并发布所有内容（除了 GET 和 DELETE），这样他们至少不会违反在某个不起眼的地方发现的一些不起眼的短语..
-
“我使用 409 来处理乐观锁异常。”如果您正在利用 HTTP 内置的条件请求功能，
412 Precondition Failed将是有意义的。 -
你是对的。不过，为了增加复杂性，我发现了以下很好的分析blog.novatec-gmbh.de/…，其中作者写道“即使在将接收到的版本与当前版本进行比较之后——这意味着在从数据库中读取存储的记录并在更新之前——可能还有另一个在同一时刻更改记录的事务。因此仍有可能发生 OptimisticLockException。在这种情况下，返回 HTTP 状态代码 409（冲突）。 :)
-
我不觉得 Schwörer 的论点有说服力，并且对依赖于实现细节的状态码深表怀疑。但无论哪种情况，REST 警察都不会追捕你。
-
"如果服务器检测到可能的冲突修改并且请求中没有定义前置条件，服务器可以返回 409（冲突）响应。" （RFC 5789）。我不保证正确解释的标准支持我的主张。