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