我正在尝试在我们的软件中实现一些PATCH请求（在https://tools.ietf.org/html/rfc7396之后）。资源中的某些字段不得修改，因此当此类字段出现在HTTP JSON请求正文中时，我正在考虑返回一些错误状态代码。 400似乎有点过于笼统（我将其用于验证错误，例如电子邮件格式等）。在这种情况下，也许还会使用其他状态代码吗？
答案 0 :(得分：2)
有一个代码。 。 。 8-）
403 Forbidden
服务器理解了该请求，但拒绝执行该请求。授权将无济于事，不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应说明原因
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
此外，即使没有凭据问题，403也适用。 RFC7231 Section 6.5.3中对此进行了解释：
出于某些原因，请求可能被禁止 与凭据无关
答案 1 :(得分：1)
RFC 7231 section 8.2状态码registry，因此是开始的地方。
这显然是请求的问题；客户端可能可以解决的问题，因此从4xx类输入是合适的。
405 Method Not Allowed在您描述的情况下是错误的-该资源将接受另一种合并补丁文档，但现有的文档不会接受。
403 Forbidden是错误的，因为它传达了与凭据有关的问题，但是您正在描述有效负载的问题。
409 Conflict可能是合理的...
由于与目标资源的当前状态存在冲突，因此无法完成请求。
我看不出有任何理由不能使冲突处于“当前状态”的不变部分。
但是我认为您最好的选择是422 Unprocessable Entity
422（不可处理实体）状态代码表示服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此为400 （错误请求）状态代码不正确），但无法处理其中的指令。例如，如果XML请求主体包含格式正确（即，语法正确）但语义上错误的XML指令，则可能会发生此错误情况。
要考虑的另一个不错的资源是HTTP Patch规范。 RFC 5789列举了补丁可能失败的多种原因，以及在每种情况下都适合使用哪种代码。您可以自己决定是否认为这些区别适合您的情况。
此状态代码可能还会显示更具体的错误，例如“冲突状态”，但更具体的错误通常会更有用。