java - patch 与 merge-patch 哪个更合适？

Question

尝试查看哪些模型最适合api(更新少，但对象结构可能经常更改，高读取应用程序)

我有这样的资源

1. Epic(ID、名称、描述、开始日期、结束日期、状态、故事)
2. 故事(ID、名称、说明、开始日期、结束日期、状态、任务)
3. 任务(ID、名称、描述、开始日期、解决日期、分辨率)

如果我只需要支持这些更新，

1. 更新Epic名称或说明或日期或状态
2. 更新故事名称或说明或日期或状态
3. 更新任务名称或说明或日期或状态

这有道理吗？

PATCH 与 application/merge-patch+json RFC 7396

资源应与目标对象结构匹配

1. 史诗/{id}
2. epics/{id1}/stories/{id2} ..等等

PATCH with application/json - 我倾向于选择这个，因为没有必要如此严格强制执行 RFC 7396 并灵活地更新更新规则。

要更新的自定义规则(但从技术上讲 - 我可以只发送需要更新的资源属性，类似于 application/merge-patch+json)

1. 史诗/{id}
2. epics/{id1}/stories/{id2} ..等等

PUT 与 application/json

资源应该匹配所有字段并创建新对象并替换(或作弊并仅像补丁中那样更新)

1. 史诗/{id}
2. epics/{id1}/stories/{id2} ..等等

PUT 与 application/json

或者作弊，只像补丁中那样更新，但使用 put

1. 史诗/{id}
2. epics/{id1}/stories/{id2} ..等等

Answer 1

从 REST 的角度来看，要记住的重要一点是统一的接口(interface) - 您拥有一些具有 application/json 表示形式的资源。我可以获取您的表示，并使用我最喜欢的工具对其进行本地编辑。

如果我想建议更改资源以匹配我的表示，我们会​​从 HTTP 协议(protocol)中选择适当的方法。换句话说，HTTP 中的方法都是“通过网络传输此文档”域的一部分。 (引用:Jim Webber, 2011)。

实际上，支持“所有这些”是确保可以使用最广泛的通用客户端与您的资源进行交互的方法。

PUT /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/json

完全合理的起点；它有几个优点 - 语义是 idempotent ，因此客户端知道丢失的请求可以重复，并且 HTTP PUT包括重要用例的语义，例如我们按原样接受您的表示，这可以让您减轻网络压力。

当表示远大于变化时，PUT 可能是一个不幸的选择。

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: ????

这是处理大表示的小变化的完全合理的方式。您放弃了 PUT 的一些优点 - 现在处理丢失的消息更加复杂。

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/json

没有任何可能。 application/json 不是 patch document格式——如果没有某种带外协议(protocol)，您无法知道这种表示正在描述什么变化。

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/vnd.example.patch+json

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/prs.example.patch+json

这是执行前一点的“REST”方式；您定义自定义媒体类型并记录语义，然后任何实现您的媒体类型的客户端都可以使用它。 vendor tree和 vanity tree可用。 +json 位是 structured syntax name suffix ，它为无法识别基本子类型的消费者提供了结构提示。

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/json-patch+json

PATCH /31E772D3-0157-4B52-8243-75EEAB946E65
Content-Type: application/merge-patch+json

也是很好的选择，因为这两种类型已在 RFC 6902 中标准化和 RFC 7936 ;您更有可能让客户已经了解这些类型。

了解 HTTP 的客户端 PATCH想必也会知道如何使用 OPTIONS 方法来发现哪些方法和 patch document formats服务器已准备好处理。

OPTIONS /31E772D3-0157-4B52-8243-75EEAB946E65

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, PUT, PATCH
Accept-Patch: application/prs.example.patch+json, application/json-patch+json, application/merge-patch+json