有人可以用简单的术语解释“超文本作为应用程序状态的引擎”

Question

这似乎是我最难以绕过头脑的REST主要内容。据我所知，在设计一个rest api时，大部分工作都应该用于设计/描述应用程序的超文本。指向这个主体的真实世界应用的指针？原子协议如何应用此主体？ 有人可以用简单的方式解释如何将其应用于假设的购物车休息api。

Answer 1

在尝试解释超媒体时，我喜欢使用通过路标与地图在汽车中导航的示例。我意识到它并没有直接回答你的问题，但它可能有所帮助。

当驾驶汽车并到达特定的十字路口时，您将获得路标以指示您可以从该点开始前往何处。同样，hypermedia根据您当前的状态为您提供一组选项。

传统的基于RPC的API更像是地图。使用地图，您倾向于根据一组静态道路数据计划您的路线。地图的一个问题是它们可能会过时，并且不会提供有关流量或其他动态因素的信息。

路标的优势在于它们可以在运行中进行更改，以便在施工时绕行交通或控制交通流量。

我并不是说路标总是比地图更好的选择。显然有利有弊，但了解两种选择都很有价值。超媒体也是如此。它是传统RPC接口的有价值的替代品。

Answer 2

考虑自己浏览常规网站。当您访问时，您会阅读页面内容，并根据您阅读的内容和您想要做的事情，按照页面上的各种链接进行操作。这真的是“超文本作为应用程序状态引擎”归结为的核心。在此示例中，应用程序状态是您头部的状态和您所在的页面。在此基础上，您将遍历更多链接，这会改变您头脑中的应用程序状态。

还有另外一个元素，请注意：它的另一面是您不应该猜测这些URI：页面中应该有足够的上下文来推断URI（例如应用程序将具有的信息）应该存在内容类型，以及诸如URI模板之类的内容，或者要遵循的URI。除此之外，RESTful HTTP应用程序不应该关心URI的结构。

更新：为了扩展，HTML表单也展示了HATEOAS。使用GET的表单类似于URI模板的使用。 HATEOS不仅限于使用HTTP GET遍历链接：使用POST（或其他一些方法，如果浏览器恰好支持它）的表单可以描述要发送到服务器的表示。

Answer 3

本文在Flickr的上下文中提供了一些示例。

Hypermedia in RESTful applications

Answer 4

另一种看待这个概念的方法是状态由当前页面和嵌入其中的链接表示。遍历链接会更改下一页表示的应用程序的状态。有点难以解释......在任何时间点可用的链接根据已经发生的操作定义可用的操作。这是“当前状态”的一个定义。

诀窍是表示可用的操作是在资源上“作用”的URI。检索与URI关联的表示会隐式执行操作并检索结果的表示。 URI嵌入在表示中，用户理解与特定URI相关联的操作。各种HTTP方法有助于定义发生的“操作”，并指定何时不允许操作。这通常是人们在描述整个RESTful范例时所得到的。