正如每个人可能已经注意到的那样,有很多假的/基本的 REST-API(它们实现了 HTTP-API 并将其称为 REST,而不遵循超文本作为应用程序状态的引擎要求,这导致Roy T. Fielding 著名的咆哮,他是第一个指定 REST 范式的人)。
我一直找不到真正超文本驱动的 REST 实现的任何实际示例,以及用于状态转换的相关应用程序特定媒体类型定义。
是否有此类实现的任何可公开访问的示例?
正如每个人可能已经注意到的那样,有很多假的/基本的 REST-API(它们实现了 HTTP-API 并将其称为 REST,而不遵循超文本作为应用程序状态的引擎要求,这导致Roy T. Fielding 著名的咆哮,他是第一个指定 REST 范式的人)。
我一直找不到真正超文本驱动的 REST 实现的任何实际示例,以及用于状态转换的相关应用程序特定媒体类型定义。
是否有此类实现的任何可公开访问的示例?
它不是运行代码意义上的实现,但我非常喜欢 InfoQ 上的文章“如何喝杯咖啡”。它将在星巴克点咖啡的过程描述为 RESTful 协议。这超出了典型的“一切都是资源”的 REST 介绍性文章,而是专注于 HATEOAS。强烈推荐。
Sun Cloud API怎么样?从介绍:
API 预设 URI 空间中没有特定的结构。起点是一个 URI,由云服务提供商提供,用于标识云本身。云的表示包含云中其他资源的 URI,以及可能在它们上执行的操作(例如部署和启动虚拟机)。
背景故事也可能会有所帮助。
Netflix 有一个基于 HATEOAS的REST API ,其中包括作为资源一部分的链接。
在 Roy 的第 4 点中,Sun Cloud API 的 RESTfulness 不是真的解决了吗:
REST API 不得定义固定的资源名称或层次结构(客户端和服务器的明显耦合)。服务器必须可以自由控制自己的命名空间。相反,允许服务器通过在媒体类型和链接关系中定义这些指令来指导客户端如何构建适当的 URI,例如在 HTML 表单和 URI 模板中完成。[这里的失败意味着客户端由于带外信息而假设资源结构,例如特定于域的标准,它是面向数据的等价于 RPC 的功能耦合]。
示例 1已定义层次结构中的固定资源名称:
来自 Sun Cloud API:“...... VDC 的表示将包括其所在集群的表示,而这些集群又包括每个集群中 VM 的表示。”
示例 2带外信息,例如特定领域的标准:
您必须拥有 wiki 页面内容(带外信息)才能知道云资源字段“uri”的“资源通信机制”是 GET。
我意识到这是不久前提出的问题,但我尝试通过一个简单的示例演示“正确的”REST API 流程。我尝试遵循 Roy 的 REST 规则 - 也许它会有所帮助: API Example using REST