rest - REST API - 处理 PATCH 中的空正文
问题描述
我目前正在为一个用 Go 编写的 REST API 做贡献,我面临着一个存在的问题。
我们应该如何处理 PATCH 中的空主体?知道 PATCH 用于更新现有数据,我们应该返回错误代码(4XX)还是正常状态(2XX)?
例如,如果我有以下路线:/user/:id
并且用户具有以下结构:
type User struct {
Name string
Email string
}
因此,如果我们 PATCH 特定用户,我们将有一个包含名称或电子邮件的正文。
如果它是空的,我们该怎么办?
RFC5789 没有真正的帮助(2.2 用于错误处理)
解决方案
我们应该如何处理 PATCH 中的空主体?
这取决于:一个空的补丁体有什么问题?
如果一个空的补丁主体是一个错误,那么您的响应应该将错误的性质传达给客户端。
如果空补丁主体不是错误,则应用空补丁。这可能是一个空操作,在这种情况下,成功!因此,您返回一个响应,说明应用空补丁是微不足道的,他们可以在这里查看更新的实现。或者,您可以204
如示例中所示。我没有看到明确说明的内容,但我认为您可以借鉴RFC 7231 第 6.3.1 节中描述的模式。
一些可能有帮助的例子。
假设客户端使用JSON Patch作为请求的媒体类型。现在,“JSON Patch 文档是表示对象数组的 JSON [RFC4627] 文档”。空请求正文不是有效的 JSON 文档,当然也不是有效的对象数组,因此这是格式错误的补丁文档,如 2.2 节所述,您应该考虑发送 400 响应。
假设客户端要发送一个带有空操作数组的 json 补丁
[]
从语义上讲,这是一个无操作——除了指示补丁已成功应用的响应将使缓存值无效。因此,您当然可以200
在不做任何事情的情况下报告成功 ( )。您可以通过返回错误来防止缓存条目失效(我认为补丁规范没有完全正确地描述语义,但我没有看到勘误表)。
类似的论点适用于application/merge-patch+json。
您可能还需要考虑RFC 5789 的勘误表
如果服务器收到一个 PATCH 请求,其媒体类型的规范没有定义特定于 PATCH 的语义,则服务器应该通过返回 415 Unsupported Media Type 状态码来拒绝该请求,除非更具体的错误状态码优先。
特别是,服务器不应该为没有定义它们的通用媒体类型假设 PATCH 语义,例如“application/xml”或“application/json”。