这不是一个技术问题，而是对该主题的反思。
REST已经使用HTTP协议实现了一种提供资源的好方法，并让开发者通过分割资源和用户界面来做最干净的项目（后端现在只使用REST API来处理后端）。关于那些API，我们大多数时候都使用GET，PUT / PATCH（嗯meh？），POST和DELETE，都模仿CRUD数据库。
但随着我们项目所花费的时间的推移，我们认为可以通过添加大量优秀功能来改善用户体验。例如，为什么用户会害怕删除资源？为什么不只是放置一个恢复系统（就像我们在Google Keep应用程序中看到的那样，我们可以撤消删除，我觉得这个删除在UX方面很棒）。
防止意外删除的一种做法是在表中使用表示资源的列。例如，我即将删除一本书，所以通过单击删除按钮，我只会将此行标记为＆＃34; deleted = TRUE＆＃34;在我的数据库中，并阻止显示浏览资源列表（GET）时删除的行。
这最后与我们亲爱的REST模式相冲突，因为DELETE和DESTROY＆＃34;方法＆＃34;之间没有区别。
我的意思是，我们是否应该考虑让REST发展到我们的用户体验需求，所以我的意思是让HTTP协议不断发展，或者这应该是一种纯粹的资源管理，我们应该遵循HTTP协议而不是试图打扰它，只是使用解决方法适应它（比如使用PATCH进行软删除）？
Personnaly我希望看到至少4个新协议，因为我们正在尝试尽可能好地限定资源：
让我思考的是我研究干净的REST解决方案来处理这种资源行为。我看过一些网站帖子，包括
建议我们使用PUT或PATCH来进行软删除，但是我觉得这听起来不对，不是吗？
我对这个问题的看法：
答案 0 :(得分：0)
即使在网络开发领域，我也不确定这是否有意义;起始处所似乎是错误的。
RFC 7231为POST
提供了此解释POST方法请求目标资源根据资源自身的特定语义处理请求中包含的表示。
谜语：如果这是POST的官方定义，为什么我们需要GET？目标可以用GET完成的任何事情也可以通过POST来完成。
答案是，对GET的额外限制允许参与者仅使用消息中包含的信息做出明智的决定。
例如，因为标题数据通知中间组件该方法是GET，所以中间人知道接收消息时的操作是safe，因此如果响应丢失，则可以重复该消息。 / p>
抓取网络的整个概念取决于您可以按照任何安全链接发现新资源这一事实。
浏览器可以预先获取表示，因为链接中编码的信息告诉它这样做的消息是安全的。
Jim Webber描述它的方式：“HTTP是一个应用程序，但它不是你的应用程序”。 HTTP规范的作用是定义消息的语义，以便通用服务器可以理解通用客户端。
使用你的例子; API使用者可能关心删除和销毁之间的区别，但浏览器不会;浏览器只是想知道要发送什么消息，重试规则是什么，缓存规则是什么，如何对各种错误条件做出反应等等。
这就是REST的强大功能 - 您可以使用任何浏览器来理解表示的媒体类型，并获得正确的行为，即使浏览器完全不了解应用程序语义。 / p>
浏览器不知道它正在与互联网留言板或路由器的控制面板通信。
总结：您的想法在我看来就好像您正在尝试通过更改消息传递语义来实现更丰富的应用程序语义;这违反了关注点。