rest - 更新项目数组中项目的 REST 最佳实践

Question

在我使用 RESTful 服务的单页应用程序中，我想知道在一组项目中更新一个项目的最佳实践是什么。

先决条件
1. 前端发出 GET 请求以获取项目列表
2. 前端格式化项目列表（即将日期从 UTC 转换为本地时间）
3. 前端向后端发出 PUT 请求更新项目的名称

可能的解决方案

解决方案 #1
4. 后端响应 HTTP-200 和单个更新项
5. 前端重新格式化更新项
6. 前端拼接项列表，查找并替换更新项

PRO
- 一个更新项目的 API 请求
CON
- 前端数据重复，没有单一的事实来源（即项目列表）

解决方案 #2
4. 后端响应 HTTP-200 和更新的项目列表
5. 前端重新格式化项目列表

PRO
- 一个API请求更新item
CON
- 不遵循单一职责原则（即更新item的API更新单个item，并返回所有item）

解决方案 #3
4. 后端响应 HTTP-200 和单个更新的项目
5. 前端发出 GET 请求以获取所有项目
6. 前端重新格式化项目列表

PRO
- 对于未来的实现更加灵活，API 遵循单一职责原则
CON
- 两个 API 请求来更新项目

score 0 · Accepted Answer

我想知道更新一组项目中的一个项目的最佳做法是什么。

了解 REST 或 HTTP 的重要一点是，我们正在设计由通用组件使用的消息。也就是说，我们正在使用易于标准化的形式来传达语义。

HTTP PUT具有将文档更新插入文档存储的语义。对于您的示例，我们获取列表资源的表示，进行本地编辑，PUT结果，有效负载是资源完整PUT表示的副本- 我们要求的是服务器使其看起来像副本就像客户的副本。

假设服务器选择将新表示应用到它的资源副本，响应的有效负载可以是状态消息（“它工作”），或者资源新表示的副本，甚至是一个空文档( 204 No Content ) 带有描述资源新表示的元数据（以及服务器未经修改就接受客户端表示的暗示）。

然而，PUT 背后的关键思想是，有效负载是资源的完整表示，而不仅仅是对其所做更改的描述。如果文档非常大（特别是与 HTTP 标头相比较大），并且您所做的编辑很小，那么您可能更愿意发送一个补丁文档来描述您对文档所做的更改，并指定PATCH请求中的方法。

当然，在 Web 上，最流行的文档格式不包括对 PUT 或 PATCH 的超媒体支持，并且最流行的客户端是浏览器，而不是文档编辑器，因此我们必须围绕POST. 所以这样做也“很好”，您只需要考虑如何将表单数据的表示应用于资源。

score 0 · Accepted Answer

解决方案 2 确实遵循单一责任原则，您可能会对命名和“责任”感到困惑，但如果我们考虑 SRP 的真正定义：“变更的单一原因” 解决方案 2 完全没问题，如果性能不是最好的方法批判的。