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请求来更新商品
CON
-不遵循单一责任原则（即用于更新商品的API会更新单个商品，并返回所有商品）

---

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

PRO
-对于将来的实现，API更加灵活，遵循单一责任原则 CON
-两个API请求来更新商品

Answer 1

解决方案2确实遵循单一责任原则，您可能会对命名和“责任”感到困惑，但是如果我们考虑SRP的真正定义：“改变的唯一原因”，解决方案2完全可以，如果性能并不关键。

https://deviq.com/single-responsibility-principle/

Answer 2

  

我想知道更新一组项目中的一项的最佳实践。

要了解有关REST或HTTP的重要一件事，就是我们正在设计要由通用组件使用的消息。也就是说，我们正在使用readily standardized forms来传达语义。

HTTP PUT具有将文档上载到文档存储中的语义。例如，在我们获取列表资源表示形式，进行本地编辑并PUT作为结果的情况下，PUT的有效负载是 complete 表示形式的副本资源–我们要问的是服务器使它的副本看起来像客户端的副本。

假设服务器选择将新的表示形式应用于其资源副本，则响应的有效负载可能是状态消息（“工作正常”）或资源的新表示形式的副本，甚至一个具有元数据的空文档（204 No Content），该元数据描述了资源的新表示形式（以及服务器未经修改即接受了客户的表示形式 的暗示）。

但是，PUT背后的关键思想是有效负载是资源的完整表示，而不仅仅是对它所做的更改的描述。如果文档很大（尤其是与HTTP标头相比很大），而您所做的编辑很小，那么您可能希望发送补丁文档来描述对文档所做的更改，并指定{请求中的{3}}方法。

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