在我指定和设计REST API的过程中，我越来越发现它非常类似于设计一个网站，其中用户的旅程以及操作和链接是故事登记的，并且对用户体验至关重要。
目前我的API设计，我返回项目和资源底部的链接。他们执行操作，改变状态或带回其他资源。
但它好像每个链接都在一个新选项卡中打开;客户探索新的路线，他们的下一个选择可能会缩小。
如果这是一个网站，它不一定是一个好的设计。用户必须在新选项卡中打开链接或者始终备份堆栈以完成任务。
好的站点只是前向的，或者确实有一种方法可以指示主流的分支，即链接在新窗口中自动打开（通过锚标签target）。
那么应该设计一个好的REST API，好像客户端丢弃当前资源并前进到下一个并始终向前推进？
或者我们假设客户正在建造一张地图，就像一个Roomba探索我们的起居室一样？
具有地图概念的东西是，人们应该知道的许多应该返回到先前资源的知识是一种有感知力的人，一种猜测。计算机无法猜测，因此需要编程，这意味着带外静态文档并打破REST。
在我指定和设计REST API的过程中，我越来越发现它与设计网站非常相似
是的 - 一个好的REST API看起来很像机器可读的网站。
那么应该设计一个好的REST API，好像客户端丢弃当前资源并前进到下一个并始终向前推进？
排序 - 允许客户端缓存表示;因此，如果您提供链接，客户端可能会“跟踪”指向缓存表示的链接，而不是使用服务器。
这也意味着客户可以自行决定“点击后退按钮”以进行其他操作（例如，如果它希望找到的链接不存在，则可能会尝试实现其目标其他方式）。这是“无国籍”约束的动机的一部分;服务器不必假装知道客户端当前显示的页面来解释消息。
计算机无法猜测，因此需要编程，这意味着带外静态文档并打破REST。
菲尔丁，writing in 2008
当然，客户有先验知识。每个协议，每个媒体类型定义，每个URI方案和每个链接关系类型构成客户必须知道（或学习）的先验知识，以便利用该知识。 REST并不能消除对线索的需求。 REST所做的是将先前知识需要集中到易于标准化的形式。这是面向数据和面向控制的集成之间的本质区别。
我在菲尔丁的原创作品中找到了这个金块。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
因此，模型应用程序是通过检查并从当前表示集合中的备选状态转换中进行选择而从一个状态移动到下一个状态的引擎。毫不奇怪，这与超媒体浏览器的用户界面完全匹配。但是，该样式并不假设所有应用程序都是浏览器。事实上，通用连接器接口会从服务器隐藏应用程序详细信息，因此用户代理同样可以是为索引服务执行信息检索的自动化机器人，寻找符合特定条件的数据的个人代理或维护蜘蛛忙于巡逻破损参考文献或修改内容的信息[39]。
它看起来像一个伟大的REST应用程序将被构建为仅向前，就像一个伟大的网站即使没有后退按钮应该很容易使用，包括前进到以前看到的表示（主页和搜索链接始终可用）。
有趣的是，我们倾向于真正考虑用户在网页设计中的旅程，而术语旅程是我们开发人员语言的一个常见部分，但在API设计中，这还没有渗透。