REST API - 在 PATCH 中处理空体

Question

我目前正在为用 Go 编写的 REST API 做出贡献，但我面临着一个存在的问题。
我们应该如何处理 PATCH 中的空体？知道 PATCH 用于更新现有数据，我们应该返回错误代码 (4XX) 还是正常状态 (2XX)？
例如，如果我有以下路线:/user/:id用户具有以下结构:

type User struct {
  Name string
  Email string
}

因此，如果我们 PATCH 特定用户，我们将有一个包含姓名或电子邮件的正文。
如果它是空的，我们应该怎么做？
RFC5789 不是真正的帮助(错误处理 2.2)
https://datatracker.ietf.org/doc/rfc5789/?include_text=1

Answer 1

How are we supposed to handle an empty body in a PATCH?

这取决于:空补丁体有什么问题？
如果一个空的补丁体是一个错误，那么你的响应应该将错误的性质传达给客户端。
如果空补丁主体不是错误，则应用空补丁。这可能是一个空操作，在这种情况下，成功!所以您返回一个响应，说明应用空补丁是微不足道的，他们可以在这里查看更新的实现。或者，您可以 204如示例所示。我没有看到明确说明的内容，但我认为您可以借鉴 RFC 7231 section 6.3.1 中描述的模式.
一些可能有帮助的例子。
假设客户端使用 JSON Patch作为请求的媒体类型。现在，“JSON Patch 文档是表示对象数组的 JSON [RFC4627] 文档”。空请求正文不是有效的 JSON 文档，当然也不是有效的对象数组，因此这是一个格式错误的补丁文档，如 2.2 节所述，您应该考虑发送 400 响应。
假设客户端要发送一个带有空操作数组的 json 补丁

[]

从语义上讲，这是一个空操作——除了表明补丁已成功应用的响应将使缓存的值无效。所以你当然可以在不做任何事情的情况下报告成功( 200 )。您可以通过返回错误来防止缓存的条目无效(我认为补丁规范并没有完全正确地描述语义，但我没有看到提交的勘误表)。
类似的论点适用于 application/merge-patch+json .
您可能还想考虑 errata for RFC 5789

If a server receives a PATCH request with a media type whose specification does not define semantics specific to PATCH, the server SHOULD reject the request by returning the 415 Unsupported Media Type status code, unless a more specific error status code takes priority.

In particular, servers SHOULD NOT assume PATCH semantics for generic media types that don't define them, such as "application/xml" or "application/json".