用于软删除和恢复软删除资源的REST是有限的

Question

这不是一个技术性问题，而是更多关于该主题的反思。

REST已经演示了一种使用HTTP协议来服务资源的好方法，并让开发人员通过分割资源和用户界面来实现最干净的项目（现在后端只使用REST API来处理后端）。

关于这些API，大部分时间我们都使用GET，PUT/PATCH（嗯？），POST和DELETE，都是模仿CRUD数据库。

但随着时间花在我们的项目上，我们觉得UX可以通过添加大量的强大功能而得到改进。例如，为什么用户觉得害怕删除资源？为什么不只是建立一个恢复系统（就像我们在Google Keep应用程序中看到的那样，可以让我们撤消在UX中我认为非常棒的删除）。

防止无意删除的做法之一是使用表中表示资源的列。例如，我即将删除一本书，因此通过单击删除按钮，我将只在数据库中将此行标记为“已删除= TRUE”，并防止显示在浏览资源列表（GET）时删除的行。 。

由于DELETE和DESTROY“方法”之间没有区别，这最后与我们亲爱的REST模式冲突。

我的意思是，我们应该考虑让REST发展到我们的用户体验需求，所以我的意思是让HTTP协议不断发展，或者应该保持纯粹的资源管理，我们应该遵循HTTP协议而不尝试打扰它，只是适应它使用解决方法（如使用PATCH软删除）？

Personnaly我希望看到至少4个新的协议，因为我们正试图资格的资源尽可能的好：

• DELETE成为防止他人的方法来对其产生影响的方式
• DESTROY成为该资源
• RECOVER是一种方式说，以其他方法“嗨，他是回来，留完全消除痕迹更剧烈调整”
• TRASH是得到这样的，但只有被删除的资源

是什么让我想想我是一个干净的REST的解决方案来处理这个资源行为的研究。我已经看到了一些网站上张贴包括

• https://www.pandastrike.com/posts/20161004-soft-deletes-http-api
• https://philsturgeon.uk/rest/2014/05/25/restful-deletions-restorations-and-revisions/
• ...

该建议我们使用PUT或PATCH，使软删除的东西可用，但我有种感觉它听起来不对，不是吗？

我对这个问题的看法：

• 有没有提出新的HTTP方法和更新先前的方法之间的一大步（听说HTTP/2是一个东西，也许我们可以把那些吗？）
• 在网络开发领域之外它有意义吗？我的意思是，这种改变可能会影响我们的其他领域吗？

Answer 1

即使在web开发领域，我也不确定这是否合理;起始前提似乎是错误的。

RFC 7231提供了这样的解释，根据资源本身的特定语义目标资源的过程中表示封闭在请求POST

POST方法请求。

谜语：如果这是POST的官方定义，为什么我们需要GET？目标可以用GET做的任何事情都可以通过POST完成。

答案是GET的附加约束条件允许参与者仅使用消息中包含的信息作出智能决策。

例如，由于标题数据通知中间组件，该方法是GET，因此中间设备知道接收到消息时的动作为safe，因此如果响应丢失，则可以重复该消息。

抓取网页的整个概念取决于您可以遵循任何安全链接来发现新资源的事实。

浏览器可以预取表示，因为编码在链接中的信息告诉它该消息是安全的。

Jim Webber描述它的方式：“HTTP是一个应用程序，但它不是你的应用程序”。 HTTP规范的作用是定义消息的语义，以便通用服务器可以理解通用客户端。

使用你的例子; API消费者可能会关心删除和销毁之间的区别，但浏览器不会;浏览器只是想知道要发送什么消息，重试规则是什么，缓存规则是什么，如何针对各种错误条件等等。

这就是REST的力量 - 您可以使用任何理解媒体类型的表示，并获得正确的行为，即使浏览器完全不了解应用程序语义。

浏览器不知道它正在与互联网留言板或路由器的控制面板通话。

总之：您的想法在我看来，好像您试图通过更改消息语义来实现更丰富的应用程序语义;这违反了关注点的分离。