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

在使用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请求更新项目

< P>解决方案2遵循单一的责任原则，您可能会被命名和“责任”混淆，但是如果我们考虑SRP的真正定义：“变更的单一原因”，解决方案2是完全好的，如果性能不重要，首选的方式是：

我想知道更新项目数组中的一个项目的最佳实践是什么

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

HTTP具有将文档升级到文档存储的语义。例如，当我们获取列表资源的表示形式，进行本地编辑，然后将结果放入

PUT

时，

PUT

的有效负载是该资源的完整表示形式的副本--我们要求的是服务器使其副本看起来像客户端的副本

假设服务器选择将新表示应用于其资源副本，则响应的有效负载可以是状态消息（“它已工作”），或资源新表示的副本，甚至是包含描述资源新表示的元数据的空文档（）（这意味着服务器未经修改就接受了客户机的表示）

然而，PUT背后的关键思想是有效负载是资源的完整表示，而不仅仅是对其所做更改的描述，并且您正在进行的编辑很小，那么您可能希望发送一个补丁文档，描述您对文档所做的更改，并在请求中指定方法

---

当然，在web上，最流行的文档格式不包括对PUT或PATCH的超媒体支持，最流行的客户端是浏览器，而不是文档编辑器，因此我们必须围绕

POST

设计更改协议。因此这很“好”要做到这一点，您只需考虑表单数据的表示将如何应用于资源。

这更多是一种辩论/暗示性质，我不确定是否值得采用堆栈溢出问题/答案模式，因为没有明确的答案。解决方案4是a）在前端本地更新项目，b）发送更新（PUT），c）如果HTTP 200显示“OK”，则处理错误（否则）。。。但不要再费心往返“更新”任何东西。无论如何：正确答案是“视情况而定”。没有一刀切的答案。对于简单的前端2后端通信，您不需要休息。如果你真的喜欢，你可以瞄准它。当您有多个使用您的服务的客户机，特别是不在您控制之下的客户机时，REST更应该是一种技术。它的目标是将客户机与服务器分离，使后者能够自由发展，而前者能够更自然地适应变化。这样，您就可以尝试使用定义良好的消息格式（简单的JSON一开始就不好）和标准化的链接关系名称来提高互操作性。