补丁与合并补丁哪个合适？

Question

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

我有这样的资源

1. 史诗（id、名称、描述、开始日期、结束日期、状态、 故事）
2. 故事（ID、名称、描述、开始日期、结束日期、状态、任务）
3. 任务（id、名称、描述、开始日期、解决日期、解决方案）

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

1. 更新史诗名称或描述或日期或状态
2. 更新故事名称或描述或日期或状态
3. 更新任务名称或描述或日期或状态

这有道理吗？

PATCH 和 application/merge-patch+json RFC 7396

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

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

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

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

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

PUT 和 application/json

资源应匹配所有字段并创建新对象并替换（或作弊并仅像在补丁中一样更新）

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

PUT 和 application/json

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

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

Answer 1

从 REST 的角度来看，要记住的重要事情是统一接口——您拥有一些带有application/json表示的资源。我可以GET代表您，并使用我最喜欢的任何工具对其进行本地编辑。

如果我想提议更改资源以匹配我的表示，我们从 HTTP 协议中选择适当的方法。换句话说，HTTP 中的方法都是“通过网络传输此文档”域的一部分。（参考：吉姆韦伯，2011 年）。

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

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

完全合理的起点；它有几个优点 - 语义是幂等的，因此客户端知道丢失的请求可以重复，并且 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 /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”方式；您定义自定义媒体类型，并记录语义，然后任何实现您的媒体类型的客户端都可以使用它。该供应商的树和虚荣的树可用。该+json位是结构化语法名称后缀，它为无法识别基本子类型的使用者提供结构提示。

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 方法来发现服务器准备处理哪些方法和补丁文档格式。

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