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

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-75EEAB946E65Content-Type: application/json完全合理的起点；它有几个优点 - 语义是幂等的，因此客户端知道丢失的请求可以重复，并且 HTTP PUT包含重要用例的语义，例如我们接受您的表示，这样可以减少网络压力。当表示远大于更改时，PUT 可能是一个不幸的选择。PATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: ????这是处理对大型表示的微小更改的一种完全合理的方法。您放弃了 PUT 的一些优点——丢失的消息现在处理起来更加复杂。PATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: application/json没有任何悬念。 application/json不是补丁文档格式——如果没有某种带外协议，您无法知道这种表示正在描述哪些变化。PATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: application/vnd.example.patch+jsonPATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: application/prs.example.patch+json这是前一点的“REST”方式；您定义一个自定义媒体类型，并记录语义，然后任何实现您的媒体类型的客户端都可以使用它。供应商树和虚荣树可用。该+json位是结构化语法名称后缀，它为无法识别基本子类型的消费者提供结构提示。PATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: application/json-patch+jsonPATCH /31E772D3-0157-4B52-8243-75EEAB946E65Content-Type: application/merge-patch+json也是很好的选择，因为这两种类型已在RFC 6902和RFC 7936中标准化；您更有可能客户已经知道这些类型。了解 HTTP PATCH的客户端大概也知道如何使用 OPTIONS 方法来发现服务器准备处理的方法和补丁文档格式。OPTIONS /31E772D3-0157-4B52-8243-75EEAB946E65HTTP/1.1 204 No ContentAllow: OPTIONS, GET, HEAD, PUT, PATCHAccept-Patch: application/prs.example.patch+json, application/json-patch+json, application/merge-patch+json