HATEOAS (REST 架构)的实际示例

正如大家可能已经注意到的那样,现在有很多假的/基本的 REST-API (它们实现了一个 HTTP-API 并称之为 REST,而没有遵循超文本作为应用程序的引擎状态的要求,这导致了 著名的罗伊 · T · 菲尔丁的咆哮,这个人首先指定了 REST 范式)。

我一直无法找到任何真正的超文本驱动的 REST 实现的实际例子,以及与状态转换相关的特定于应用程序的媒体类型定义。

是否有此类实现的公开可访问的实例?

49660 次浏览

它不是运行代码的实现,但我真的很喜欢 InfoQ 上的文章“ 如何得到一杯咖啡”。它将在星巴克点咖啡的过程描述为一个 RESTful 协议。这超出了典型的“一切都是资源”的 REST 介绍性文章的范围,主要关注 HATEOAS。强烈推荐。

Sun Cloud API呢? 简介:

API 在 URI 空间中不预设任何特定的结构。起点是由云服务提供商提供的 URI,它标识云本身。云的表示包含云中其他资源的 URI,以及可能对它们执行的操作(例如部署和启动虚拟机)的 URI。

背景故事可能也有帮助。

Sun Cloud API 的 RESTful 不是在 Roy 的第四点中提到的吗:

REST API 不能定义固定的资源名称或层次结构(客户端和服务器的明显耦合)。服务器必须能够自由地控制自己的名称空间。相反,通过在媒体类型和链接关系中定义这些指令,允许服务器指示客户端如何构造适当的 URI,比如在 HTML 表单和 URI 模板中。[此处的失败意味着客户端由于带外信息而假设资源结构,比如特定于域的标准,这是面向数据的等价于 RPC 的功能耦合]。

示例1 已定义层次结构中的固定资源名称:

来自 Sun Cloud API: “ ... VDC 的表示将包括驻留在其中的集群的表示,而集群又包括每个集群中的 VM 的表示。”

示例2 带外信息,例如特定于域的标准:

您必须拥有 wiki 页面的内容(带外信息)才能知道云资源字段“ uri”的“资源通信机制”是 GET。

Netflix 有一个基于 HATEOAS 的 REST API,其中包括作为资源一部分的链接。

我意识到这个问题已经提出一段时间了,但是我尝试为一个简单的示例演示一个“合适的”REST API 流。我试图遵循罗伊的 REST 规则——也许它会有所帮助: 使用 REST 的例子