首页猿问补丁与合并补丁哪个合适？

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

Java

肥皂起泡泡 2022-11-10 16:43:19

尝试查看哪些模型最适合api（低更新，但对象结构可能经常更改，高读取应用程序）我有这样的资源史诗（id、名称、描述、开始日期、结束日期、状态、故事）故事（id、名称、描述、开始日期、结束日期、状态、任务）任务（id、名称、描述、开始日期、解决日期、解决方案）如果我只需要支持这些更新，更新史诗名称或描述或日期或状态更新故事名称或描述或日期或状态更新任务名称或描述或日期或状态这有道理吗？PATCH和application/merge-patch+json RFC 7396资源应该匹配目标对象结构史诗/{id}史诗/{id1}/stories/{id2} .. 等等PATCHwithapplication/json -我倾向于选择这个，因为没有必要如此严格地执行RFC 7396和灵活地更新更新规则。您要更新的自定义规则（但从技术上讲 - 我可以只发送需要更新的资源属性，类似于application/merge-patch+json）史诗/{id}史诗/{id1}/stories/{id2} .. 等等PUT和application/json资源应匹配所有字段并创建新对象并替换（或作弊并仅像补丁一样更新）史诗/{id}史诗/{id1}/stories/{id2} .. 等等PUT和application/json或作弊，只更新补丁，但使用 put史诗/{id}史诗/{id1}/stories/{id2} .. 等等

查看完整描述

1 回答

慕容3067478

TA贡献1773条经验获得超3个赞

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

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

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

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

Content-Type: application/json

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

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