0

这不是一个技术问题，而是对这个主题的反思。

REST 已经民主化了一种使用 HTTP 协议提供资源的好方法，并让开发人员通过拆分资源和用户界面来做最干净的项目（后端现在真的只使用 REST API 来处理后端）。

关于这些 API，大多数时候我们使用 GET、PUT/PATCH（嗯？）、POST 和 DELETE，它们都模仿 CRUD 数据库。

但是随着我们项目花费的时间的流逝，我们觉得可以通过添加大量出色的功能来改进用户体验。例如，为什么用户会害怕删除资源？为什么不只是放置一个恢复系统（就像我们在 Google Keep 应用程序中看到的那样，它可以让我们撤消删除，我认为这在 UX 方面很棒）。

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

最后一个与我们亲爱的 REST 模式相冲突，因为 DELETE 和 DESTROY “方法”之间没有区别。

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

Personnaly 我希望看到至少 4 个新协议，因为我们正在尝试尽可能好地限定资源：

  • DELETE成为一种防止其他方法对其产生影响的方法
  • 通过完全删除此资源的痕迹，DESTROY变得更加引人注目
  • RECOVER是一种对其他方法说“嘿，伙计们，他回来了，敬请期待”的方式
  • TRASH类似于 GET 但仅适用于 DELETED 资源

让我想到它的是我对处理这种资源行为的干净 REST 解决方案的研究。我看过一些网站帖子，包括

这建议我们使用 PUT 或 PATCH 使软删除变得可用，但我觉得这听起来不对，不是吗？

我对这个问题的想法：

  • 在提出新的 HTTP 方法和更新以前的方法之间是否有很大的进步（我听说 HTTP/2 是一回事，也许我们可以将它们发布？）
  • 在网络开发领域之外有意义吗？我的意思是这种变化是否会影响我们的其他域？
4

1 回答 1

-1

即使在 Web 开发领域，我也不确定这是否有意义。起始前提似乎是错误的。

RFC 7231 为POST提供了这种解释

POST 方法请求目标资源根据资源自己的特定语义处理请求中包含的表示。

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

答案是 GET 的附加限制允许参与者仅使用消息中包含的信息做出明智的决定。

例如，由于头部数据通知中间组件该方法是 GET，因此中间层知道收到消息后的操作是安全的，因此如果响应丢失，则可以重复该消息。

抓取网络的整个概念取决于您可以通过任何安全链接来发现新资源这一事实。

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

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

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

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

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

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

于 2017-07-25T17:06:39.370 回答