正如大家可能已经注意到的那样，野外有很多虚假/基本的REST-API（实现HTTP-API并将其称为REST而不遵循超文本作为应用程序状态引擎的要求，这导致famous rant of Roy T. Fielding，首先指定REST范例的人。
我一直无法找到真正的超文本驱动的REST实现的任何实际示例，以及状态转换的相关应用程序特定媒体类型定义。
是否有任何可公开访问的此类实施示例？
答案 0 :(得分：99)
它不是运行代码意义上的实现，但我非常喜欢InfoQ上的文章“How to GET a cup of coffee”。它描述了在星巴克订购咖啡作为RESTful协议的过程。这超出了典型的“一切都是资源”REST入门文章，并侧重于HATEOAS。强烈推荐。
答案 1 :(得分：21)
Sun Cloud API怎么样？从介绍：
API预先假定URI空间中没有特定的结构。起点是由云服务提供商提供的URI，用于标识云本身。云的表示包含云中其他资源的URI，以及可以对其执行的操作（例如，部署和启动虚拟机）。
backstory也可能会有所帮助。
答案 2 :(得分：7)
Netflix有一个基于HATEOAS的REST API，其中包含作为资源一部分的链接。
答案 3 :(得分：3)
在Roy的第四点中，不是Sun Cloud API的RESTful实际解决了：
REST API不能定义固定资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI，例如在HTML表单和URI模板中完成的。 [这里的失败意味着客户端由于带外信息而假定资源结构，例如特定于域的标准，这是面向数据的，与RPC的功能耦合等效。]
示例1 已定义的heirachy中的固定资源名称：
来自Sun Cloud API：“...... VDC的表示将包括居住在其中的群集的表示，其反过来包括每个群集中虚拟机的表示。”
示例2 带外信息，例如特定于域的标准：
您必须拥有维基页面内容（带外信息）才能知道云资源字段“uri”的“资源通信机制”是GET。
答案 4 :(得分：3)
我意识到这是前一段时间被问到过的，但我为了一个简单的例子，我试图展示一个“适当的”REST API流程。我试图遵循Roy的REST规则 - 也许它可以帮助： API Example using REST