“你相信他吗？” 蹄检察官责备地说。 “好吧，您怎么看，未经您的允许，我会承担这些责任吗？”
“那么，你权衡了吗？” 哭泣的奥斯塔普。 -为什么？
-帕尼科夫斯基说他们是金子。
奥斯塔普看着帕尼科夫斯基。 直到现在，他才注意到在他的夹克下面，衬衫的正面不超过五十美元，从那里，上帝赤裸的目光注视着日光。 一言不发，伟大的组合者掉进了椅子。 他摇了摇，双手悬在空中。 然后，他的喉咙爆发出隆隆的火山隆隆声，泪水从他的眼睛里流出来，笑声影响了整夜的疲倦，以及与Koreiko的战斗中令人失望的一切，而这由他的牛奶兄弟可悲地嘲笑了。
借助这段经典片段，我想作为Roy T的翻译的序幕。Fielding博客文章REST API必须是超文本驱动的。 特别感谢
habr.com/users/arthuriantech提供的材料链接。
Habré上的这一周被标记为REST（完整）API的一周。 从这个意义上说，我一直对这个术语中的REST前缀感到困惑。 而且，事实证明，不仅仅是我。 今天，我将亲自阅读它，并邀请所有人了解Roy T. Fielding在2008年的想法。 当然，有人紧张地在凳子上爬行，并说：告诉罗伊，贝尼亚知道REST API。 尽管如此，我们将开始。
想到有多少人基于HTTP协议REST API调用任何接口，我感到沮丧。 今天的示例是REST SocialSite API。 这是一个RPC。 这是公然的RPC。 它表明了如此艰难的联系，现在是他分配硬色情类别的时候了。
为了使他们理解超文本是REST体系结构中的必要元素，需要做什么？ 换句话说，如果应用程序状态机制（以及因此的API）不是基于超文本的，则它不能是RESTful的，也不能是REST API。 重点。 我应该重写哪本书以使其清楚？
API开发人员，在调用REST API创建之前，请注意以下规则：
REST API不应依赖于特定的通信协议，尽管其成功映射到该协议可能取决于元数据的可用性，方法的选择等。通常，URI方案中的任何协议都应允许将任何URI方案用于标识。 [这里的错误是标识与交互不是分开的。]
REST API不应包含对通信协议的任何更改，除非填写或更正了标准协议定义不充分的位（例如HTTP PATCH方法或链接头字段）的细节。 非工作实现（例如，愚蠢到足以相信HTML定义了一组HTTP方法的浏览器）的变通办法必须单独确定，或者至少在应用程序中确定，并希望变通办法最终会过时。 [这里的错误是资源接口是特定的而不是通用的。]
REST API应该将其几乎所有的描述性工作都花在定义用于表示资源的媒体类型，管理应用程序状态以及定义对现有标准媒体类型的超文本支持的扩展关系和标记名称上。 花费所有精力描述将哪些方法用于感兴趣的URI应该完全定义为媒体类型（在大多数情况下，已经由现有媒体类型定义）的处理规则的一部分。 [这里的错误是资源外部的信息控制了交互而不是超文本。]
REST API不应定义固定的资源名称或名称空间（紧密的客户端-服务器连接）。 服务器必须具有管理自己的名称空间的自由。 相反，让服务器指示客户端如何创建适当的URI，例如以HTML形式和URI模板，以媒体类型和引用关系定义这些指令。 [这里的错误是资源的结构是在此资源之外设置的，例如，在特定于域的标准中，它实际上是RPC功能关系的类似物]。
REST API永远不应具有对客户端重要的“类型化”资源。 规范作者可以使用资源类型来描述接口背后的服务器实现，但是这些类型对于客户端而言必须是不相关且不可见的。 对于客户端而言，唯一重要的类型是当前视图的媒体类型和标准化的关系名称。 [请参阅 以上]
在输入REST API之前，除了初始URI和适合目标受众的一组标准化媒体类型（即可以在使用API的客户端上期望的）之外，应该没有其他任何先验知识。 从这一刻起，应通过选择服务器提供的接收视图中存在的选项或用户对这些视图的操作来确定应用程序状态的所有转换。 可以通过客户对媒体类型和资源通信机制的知识来确定（或限制）转换，这些知识可以实时改进（例如，按要求提供代码）。 [这里的错误是资源外部的信息控制了交互而不是超文本。]
也许我错过了一些东西，但是以上是超文本必不可少的规则，在所谓的REST API中最经常违反这些规则。 请尝试坚持使用它们，或为您的API选择另一个流行词。
Roy T. Fielding的帖子在评论中引发了讨论。 我建议熟悉部分讨论，并附上作者的回答。
问题：
您在什么意义上使用“超文本”一词？ 我是否必须阅读您的作品才能理解您的意思，或者在线上有什么可以揭示这个概念的含义？
答案是：
我在REST演讲中有一张幻灯片，解释了超文本（和超媒体）的含义。
超文本有许多定义：
Ted Nelson的最初定义集中于非线性文档。
“超文本”是指非线性文档-可以分叉并允许读者进行选择的文本，该文档易于在交互式屏幕上阅读。 通常认为，这是一系列文本块，这些文本块通过链接为读者提供各种途径。 [西奥多·尼尔森]
超文本后来与特定的用户界面机制相关联。
超文本是计算机支持的存储介质，其中相关文档及其链接显示在高分辨率计算机屏幕上。 [杰弗里·康克林]
当我说“超文本”时，是指同时呈现信息和控件，使信息可用，因此用户（或机器）可以选择并选择操作。 超媒体只是文本含义的扩展，在媒体流中包括临时锚点。 大多数研究人员拒绝这种区分。
对于浏览器，超文本不必是HTML。 当机器了解数据格式和关系类型时，它们可以跟随链接。
Dave Johnson（受批评的API的作者）：
也许我措词模糊。 我从来没有想过说OpenSocial或SocialSite RPC API是RESTful的。 有关我的博客rollerweblogger.org/roller/entry/the_x_rated_socialsite_api的更多信息 。
答案是：
OpenSocial RESTful协议不是RESTful。 可以通过较小的更改来解决此问题，但是现在，它只是将RPC结果打包到常见的网络媒体类型中。
真正的RESTful API看起来像超文本。 信息的每个可寻址单元都携带一个地址，该地址可以是显式的（例如，链接和id属性），也可以是隐式的（例如，从介质类型和表示结构的定义中获得）。 查询结果由具有摘要信息的链接列表表示，而不是由对象表示形式的数组表示（查询不会替换资源标识）。 资源表示形式是自记录的：客户端不需要知道此资源是否是OpenSocialist，因为它只会影响所接收的表示形式。
从Internet上考虑它。 有多少网络浏览器知道在线银行资源和Wiki之间的区别？ 没有一个。 他们不需要了解资源类型。 他们需要知道的是潜在的状态转换：链接和形式，以及遍历这些链接时所隐含的语义或动作。 浏览器将它们呈现为单独的用户界面控件，以便用户可以看到潜在的过渡并预期所选动作的效果。 机器人可以按照已知的动作安全地进行跟踪。 类型化的关系，特定的媒体类型以及与操作有关的元素提供了自动化代理所需的指导。
有用的链接：
1.
habr.com/us/users/arthuriantech的 翻译版本2.
老罗伊的论点相同