在我指定和设计REST API的那些年里，我越来越发现它与设计网站非常相似，在该网站上，用户的旅程，动作和链接具有故事性，并且对UX至关重要。
当前使用我的API设计，我返回项目中和资源底部的链接。他们执行动作，改变状态或带回其他资源。
但是，好像每个链接都在新选项卡中打开一样；客户会探索一条新路线，随着他们的前进，他们的下一个选择可能会缩小。
如果这是一个网站，那不一定是一个好的设计。用户必须一直在新选项卡中打开链接，或者一直备份堆栈以完成任务。
好的网站只能转发，或者确实有一种方法可以指示主流以外的分支，即链接会自动在新窗口中打开（通过锚标记 <?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
<item
android:left="3px"
android:right="-5px"
android:top="-5px"
android:bottom="-5px">
<shape xmlns:android="http://schemas.android.com/apk/res/android"
android:shape="rectangle">
<stroke
android:width="4px"
android:color="@color/colorPrimary"
android:dashGap="20px"
android:dashWidth="20px" />
</shape>
</item>
</layer-list>
）。
那么，是否应该设计一个好的REST API，就像客户端丢弃当前资源并前进到下一个资源并始终向前推进一样？
还是我们假设客户正在构建地图，例如umroomba正在探索我们的客厅？
关于地图概念的事情是，在可能感知的许多知识中，人们应该返回到先前的资源的知识是一种有感知力的人，这是一种猜测。计算机无法猜测，因此需要编程，这意味着带外静态文档并破坏了REST。
答案 0 :(得分：1)
在我指定和设计REST API的那几年，我越来越发现它与设计网站非常相似
是的-良好的REST API看起来很像机器可读的网站。
那么，是否应该设计一个好的REST API，就像客户端丢弃当前资源并前进到下一个资源并始终向前推进一样？
排序-允许客户端缓存表示；因此，如果您提供一个链接，则客户端可以将链接“链接”到缓存的表示形式，而不是使用服务器。
这也意味着客户端可以自行决定“按后退按钮”以执行其他操作（例如，如果不存在其希望查找的链接，则它可能会尝试以另一种方式实现其目标）。这是“无状态”约束的动机的一部分。服务器不必假装知道客户端当前显示的页面来解释消息。
计算机无法猜测，因此需要编程，这意味着带外静态文档并破坏了REST。
Fielding，writing in 2008
客户当然有先验知识。每个协议，每个媒体类型定义，每个URI方案和每个链接关系类型都构成了客户端必须知道（或学习）的先验知识，以便利用该知识。 REST并没有消除线索的必要。 REST的工作是将对先验知识的需求集中到易于标准化的形式中。这就是面向数据的集成和面向控制的集成之间的本质区别。
答案 1 :(得分：0)
我在Fielding的原始作品中找到了这个块。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
因此，模型应用程序是一种引擎，它可以通过检查并从当前表示形式的替代状态转换中进行选择，从而从一种状态转换为另一种状态。毫不奇怪，这与超媒体浏览器的用户界面完全匹配。但是，该样式并不假定所有应用程序都是浏览器。实际上，通用连接器接口从服务器隐藏了应用程序的详细信息，因此用户代理可以是为索引服务执行信息检索的自动机器人，寻找与某些条件匹配的数据的个人代理或维护Spider忙于巡查信息以获取损坏的参考文献或修改过的内容[39]。
这听起来像是一个很棒的REST应用程序将被构建为仅可转发，就像一个很棒的网站即使没有后退按钮也应该易于使用，包括前进到以前看到的表示形式（主页和搜索链接始终可用）。
有趣的是，我们倾向于真正考虑网页设计中的用户旅程，而旅程一词是我们开发人员语言的常见组成部分，但在API设计中，这一点尚未渗透。