REST - API 客户端是否应该像浏览器一样“推进”到“下一个”资源？

Question

在我指定和设计 REST API 的这些年中，我越来越发现这与设计一个网站非常相似，在该网站中，用户的旅程、操作和链接都是故事板，并且对 UX 至关重要。

在我目前的 API 设计中，我在项目和资源底部返回链接。它们执行操作、改变状态或恢复其他资源。

但好像每个链接都在一个新标签页中打开；客户探索了一条新路线，他们的下一个选择可能会随着时间的推移而缩小。

如果这是一个网站，它不一定是一个好的设计。用户必须在新选项卡中打开链接或一直备份堆栈才能完成工作。

好的网站只是转发的，或者确实有一种方法可以表明主流的分支，即在新窗口中自动打开链接（通过锚标记target）。

那么，一个好的 REST API 是否应该被设计成客户端丢弃当前资源并前进到下一个并始终向前推进？

或者我们是否假设客户正在构建地图，例如正在探索我们客厅的 Roomba？

关于地图概念的事情是，一个人应该返回到以前的资源的知识，在它可能知道的许多资源中，是在一个有知觉的人类身上，一种猜测。计算机无法猜测，因此需要编程，这意味着带外静态文档和破坏 REST。

Answer 1

在我指定和设计 REST API 的这些年里，我越来越发现它与设计网站非常相似

是的 - 一个好的 REST API 看起来很像机器可读的网站。

那么，一个好的 REST API 是否应该被设计成客户端丢弃当前资源并前进到下一个并始终向前推进？

排序 - 允许客户端缓存表示；因此，如果您提供链接，客户端可能会“跟随”链接到缓存的表示，而不是使用服务器。

这也意味着客户端可以自行决定“点击后退按钮”以离开并执行其他操作（例如，如果它希望找到的链接不存在，它可能会尝试以另一种方式实现其目标）。这是“无状态”约束的部分动机；服务器不必假装知道客户端当前显示的页面来解释消息。

计算机无法猜测，因此需要编程，这意味着带外静态文档并破坏 REST。

外勤，writing in 2008

当然，客户有先验知识。每个协议、每个媒体类型定义、每个 URI 方案和每个链接关系类型都构成了客户端必须知道（或学习）才能使用该知识的先验知识。 REST 并没有消除对线索的需求。 REST 所做的是将对先验知识的需求集中到易于标准化的形式中。这是面向数据的集成和面向控制的集成的本质区别。

Answer 2

我在菲尔丁的原创作品中发现了这个金块。

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

因此，模型应用程序是一个引擎，它通过检查并从当前表示集中的替代状态转换中进行选择，从一个状态移动到下一个状态。毫不奇怪，这与超媒体浏览器的用户界面完全匹配。但是，该样式并不假定所有应用程序都是浏览器。事实上，应用程序的详细信息通过通用连接器接口对服务器隐藏，因此用户代理同样可以是为索引服务执行信息检索的自动机器人、寻找符合特定标准的数据的个人代理或维护蜘蛛忙于在信息中巡查损坏的引用或修改的内容 [39]。

它看起来就像一个伟大的 REST 应用程序将被构建为仅向前，就像一个伟大的网站应该易于使用，即使没有后退按钮，包括前进到以前看到的表示（主页和搜索链接始终可用）。

有趣的是，我们倾向于真正考虑网页设计中的用户旅程，而旅程一词是我们开发人员语言的常见部分，但在 API 设计中这还没有渗透。