REST API - 在PATCH

时间:2018-05-30 13:21:28

标签: rest api

我目前正在为使用Go编写的REST API做出贡献,而我正面临一个存在问题。

我们如何处理PATCH中的空体?知道PATCH用于更新现有数据,我们是否应该返回错误代码(4XX)或ok状态(2XX)?

例如,如果我有以下路线:/user/:id

用户具有以下结构:

type User struct {
  Name string
  Email string
}

因此,如果我们PATCH特定用户,我们将拥有一个包含该名称或电子邮件的正文。

如果它为空,我们该怎么办?

RFC5789不是真正的帮助(2.2用于错误处理)

https://datatracker.ietf.org/doc/rfc5789/?include_text=1

非常感谢你!

2 个答案:

答案 0 :(得分:4)

  

我们如何处理PATCH中的空体?

这取决于:空补丁体有什么问题?

如果空补丁正文出错,那么您的回复应该将错误的性质告知客户。

如果空补丁体不是错误,则应用空补丁。这可能是一个无操作,在这种情况下,成功!因此,您返回一个响应,解释应用空补丁是微不足道的,这里他们可以去看看更新的实现。或者,您可以204,如示例中所示。我没有看到明确说明的内容,但我认为你可以利用RFC 7231 section 6.3.1中描述的模式。

可能会有所帮助的一些例子。

假设客户端使用JSON Patch作为请求的媒体类型。现在,“JSON补丁文档是一个表示对象数组的JSON [RFC4627]文档”。空请求正文是一个有效的JSON文档,当然不是有效的对象数组,因此这是一个格式错误的补丁文档,如2.2节所述应该考虑发送400响应。

假设客户端发送带有空操作数组的json补丁

[]

从语义上讲,这是一个no-op - ,除了,表明补丁已成功应用的响应将使缓存的值无效。所以你当然可以报告成功(200)没有做任何事情。您可能能够通过返回错误来阻止缓存的条目失效(我认为补丁规范并未正确描述语义,但我没有看到错误提交的文章)。 / p>

类似的论点适用于application/merge-patch+json

您可能还想考虑errata for RFC 5789

  

如果服务器接收到具有其规范未定义特定于PATCH的语义的媒体类型的PATCH请求,则服务器应该通过返回415 Unsupported Media Type状态代码来拒绝该请求,除非更具体的错误状态代码优先。

     

特别是,服务器不应该假定没有定义它们的通用媒体类型的PATCH语义,例如“application / xml”或“application / json”。

答案 1 :(得分:0)

MDN 在此处的示例中使用了 204 No Contenthttps://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH#response