PATCH 方法是不是应该在响应正文中返回资源的所有字段？

Posted 2023-03-03

【中文标题】PATCH 方法是不是应该在响应正文中返回资源的所有字段？

【英文标题】：Should the PATCH method return all fields of the resource in the response body?PATCH 方法是否应该在响应正文中返回资源的所有字段？

【发布时间】：2016-10-09 15:26:55

【问题描述】：

PATCH 方法是否应该在响应正文中返回资源的所有字段？ 还是应该只返回更新的字段？

我正在阅读this

例如，如果它只返回更新的字段，则用户可以知道服务器中更新了哪些字段，而用户更新了一些字段。

**Users resource representations**
name: string
age: number
createdon: date
modifiedon: date

PATCH /users/userId
Request body

  name: 'changedname',

Response body Case1

  name: 'changedname',
  age: 20,
  createdon: 2016-01-01,
  modifiedon: 2016-06-09

Response body Case2

  name: 'changedname',
  modifiedon: 2016-06-09

【参考方案1】：

通常这应通过content negotiation 处理。换句话说，客户要求提供一个特定的表示，如果它需要的话。请求如下所示：

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.user+json
...

在这种情况下，客户端表示它想要一个完整的user 表示作为答案。或者它可以这样做：

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.object-fragment+json
...

请求某个对象的通用片段表示。

如果您不想同时实现，则不必同时实现，在这种情况下，您只需执行您的用例并回复406 Not Acceptable 到您暂时不支持的media-types。

【参考方案2】：

PATCH 的规范没有强制要求。

如果您想控制它，您可能需要查看https://greenbytes.de/tech/webdav/rfc7240.html#return 以获得灵感。

【讨论】：

非常棒的建议，依赖于 Prefer 标头。

【参考方案3】：

我不认为 REST 规范（顺便说一句，我认为您需要为此查看 RFC 6902）对此（您应该返回的内容）强制执行任何严格的规则。我宁愿返回整个资源，以便客户可以以任何需要的方式使用它。从理论上讲，客户端自己知道修补了什么（至少请求是什么）。从服务器获得确认可能不是一件容易的事（尤其是考虑到 PATCH 主要用于收集），或者至少不值得。

【讨论】：

在 RFC 5789 的第 2.1 节中有一个定义：tools.ietf.org/html/rfc5789#section-2.1

虽然奇​​怪的是它提到了一个文件，但没有别的。 Successful PATCH response to existing text file: HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"

但是，它也说：Note that other success codes could be used as well.（除了204）