Question

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

我有这样的资源

史诗（ID，名称，描述，开始日期，结束日期，状态，故事）
故事（ID，名称，描述，开始日期，结束日期，状态，任务）
任务（ID，名称，描述，开始日期，解决日期，分辨率）

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

更新史诗名称或描述或日期或状态
更新故事的名称或描述或日期或状态
更新任务名称或描述或日期或状态

哪个有意义？

PATCH和application/merge-patch+json RFC 7396

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

史诗/ {id}
史诗/ {id1} /故事/ {id2} ..依此类推

PATCH和application/json -我倾向于选择此选项，因为不需要如此严格地执行RFC 7396和灵活性更新更新规则。

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

史诗/ {id}
史诗/ {id1} /故事/ {id2} ..依此类推

PUT和application/json

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

史诗/ {id}
史诗/ {id1} /故事/ {id2} ..依此类推

PUT和application/json

或作弊，仅像补丁中那样进行更新，但使用put

史诗/ {id}
史诗/ {id1} /故事/ {id2} ..依此类推

Answer 1

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

如果我随后建议更改资源以匹配我的表示形式，请从HTTP协议中选择适当的方法。换句话说，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格式-如果没有某种带外分歧，您将无法知道这种表示形式所描述的变化。

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

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

1 个答案: