为不受支持的 PATCH 返回的 HTTP 代码答案

【问题标题】：HTTP code to return for unsupported PATCH为不受支持的 PATCH 返回的 HTTP 代码
【发布时间】：2025-11-25 11:00:02
【问题描述】：

我正在 dropwizard REST 资源上实现 PATCH 方法。目前只有资源的一部分属性需要修补。并且目前只能实现替换操作。

如果我看到 PATCH 请求不支持的属性/路径，我应该返回哪个 HTTP 代码？如果请求了不受支持的add 或remove 操作，我应该返回什么？

【问题讨论】：

【解决方案1】：

如果我看到 PATCH 请求不支持的属性/路径，我应该返回哪个 HTTP 代码？

在这种情况下，服务器应返回405 以指示目标资源不支持HTTP 方法。除了状态码，服务器还必须返回一个Allow 标头，列出该资源支持的方法：

6.5.5. 405 Method Not Allowed

405（不允许的方法）状态码表示该方法在请求行中收到的原始服务器知道但不知道由目标资源支持。源服务器必须生成一个 405 响应中的 Allow 标头字段包含目标列表资源当前支持的方法。

如果请求了不受支持的add 或remove 操作，我应该返回什么？

我假设您的意思是来自 JSON Patch 的 add 和 remove 操作，这是一个 JSON 文档，描述了应用于 JSON 文档的一系列操作，适合与 PATCH HTTP 方法一起使用。

因此请查看RFC 5789 的error handling 部分，该文档定义了PATCH HTTP 方法。

你的问题中描述的情况，其实是一个实体，由于语义的原因，服务器无法处理。所以422是一个合理的选择，根据RFC 5789：

无法处理的请求： 可以用 422 指定（无法处理 Entity) 响应时服务器了解补丁文档和补丁的语法文档似乎有效，但服务器无法处理请求。这可能包括尝试修改以某种方式导致资源无效的资源；例如，对格式良好的 XML 文档的修改会导致它不再是格式良好的。 [...]

还要记住同一文档中的以下建议：

错误响应的实体主体应该包含足够的信息将错误的性质传达给客户。内容- 响应实体的类型可能因实现而异。

RFC 7807 定义了可用于报告 HTTP API 问题的文档格式。

【讨论】：

我意识到我的帖子可以解释为两个问题。所以我会选择这个作为答案。我打算问的问题的答案是第二个问题，代码 422。我的意思是支持 PATCH 动词。但仅适用于 json 补丁文档中的某些“路径”值（不是 url 路径）。并且仅适用于“op:replace”。

【解决方案2】：

我的投票是 405：

405 方法不允许

不支持请求方法请求的资源；例如，表单上的 GET 请求需要要通过 POST 或只读 PUT 请求呈现的数据资源。

再加上 Cassio 提出的关于提供足够信息来描述错误的建议。

【讨论】：

405 不适合这种情况，一旦它表明PATCH 本身不受资源支持。引用RFC 7231: "405 (Method Not Allowed) 状态码表示请求行中接收的方法 源服务器已知但目标不支持资源。”
@CassioMazzochiMolin - OP 说“如果我看到不支持的属性/路径的 PATCH 请求，我应该返回哪个 HTTP 代码”。这不正是您刚刚引用的 - “资源不支持该方法”吗？对我来说，使用 WEBDAV 特定代码似乎是错误的方式。
原来 OP 有两个不同的问题（我最初忽略了这一点）。您的回答解决了特定资源不支持 PATCH 的情况。因此，我赞成您的回答。