HATEOAS:简明描述 [英] HATEOAS: concise description

问题描述

我试图对 HATEOAS 有一个清晰简洁的理解，我绝不是 WRT REST 专家.(我想我明白了，多亏了这个 http://www.looah.com/source/视图/2284).

I am trying to get a clear and concise understanding of HATEOAS, and I am by no means an expert WRT REST. (I think I get it though, thanks to this http://www.looah.com/source/view/2284 ).

谁能推荐一篇同样有启发性的博客/文章 WRT HATEOAS?

Can anyone suggest an equally enlighenting blog/article WRT HATEOAS?

推荐答案

超媒体约束(以前称为 HATEOAS)是一种用于为用户代理提供方向的约束.

The Hypermedia Constraint (formerly known as HATEOAS) is a constraint that is used to provide direction to the user-agent.

通过在返回的表示中包含链接，服务器可以消除用户代理根据当前应用程序状态确定可以采取哪些操作并知道按顺序与谁交互的负担以实现该目标.

By including links in returned representations, the server can remove the burden from the user-agent of determining what actions can be taken based on the current application state and knowing who to interact with in-order to achieve that goal.

因为除了在请求中接收到的内容之外，服务器不知道用户代理的当前状态，所以用户代理尽量避免使用服务器返回的表示以外的状态是很重要的.这确保了服务器提供的可用操作尽可能基于对用户代理状态的最完整理解.

As the server has no knowledge of the user-agent's current state other than what it receives in a request, it is important that the user-agent tries to avoid using state other than the representations returned from the server. This ensures that the available actions provided by the server are based the most complete understanding of the user-agent state as possible.

符合超媒体约束的用户代理就像一个状态机，其中状态转换是由当前表示中可用的链接引起的.返回的表示成为新的状态.

A user-agent conforming to the Hypermedia constraint acts like a state machine, where state transitions are caused by following links available in the current representation. The returned representation becomes the new state.

这种方法的好处是一个非常轻量级的用户代理.它只需要很少的代码来管理状态，因为它的操作应该完全基于接收到的响应和检索该响应的链接.用户代理代码变成声明性和反应性的，而不是 GET this then do this 然后 do that 的命令式序列，您只需拥有跟踪链接的机制和许多实例 WHEN 你收到这个 THEN do that.

The benefits of this approach can be a very lightweight user-agent. It requires very little code to manage state as its actions should be based purely on the received response and the link that retrieved that response. The user agent code becomes declarative and reactive, rather than imperative sequences of GET this then do this and then do that, you simply have the mechanics for following links and many instances of WHEN you receive this THEN do that.

有关其工作原理的示例，您只需查看您的网络浏览器和不使用 Javascript 的网站即可.浏览器根据 HTML 中的链接为您提供选项.当您点击该链接时，浏览器会将其当前状态替换为您点击该链接时检索到的新状态.后退按钮起作用(或至少应该起作用)，因为您正在从历史记录中的链接检索状态.浏览器不应该关心您是如何到达页面的，因为状态应该完全基于检索到的表示.

For an example of how this works, you need look no further than your web browser and a web site that doesn't use Javascript. The browser presents you with options based on links in the HTML. When you follow that link, the browser replaces its current state with the new state retrieved when you followed the link. The back button works (or at least should) because you are retrieving the state from a link in your history. The browser should not care how you got to the page, as the state should be based entirely on the retrieved representation.

这种状态管理"模型可能非常有限，因为您当前的应用程序状态基于单个服务器响应.但是，可以通过使用一组协同工作的用户代理来构建复杂的应用程序.这是 AJAX 实现的一部分，因为它允许使用不同的用户代理来发出单独的请求，因此实际上管理另一个状态机.不幸的是，大多数时候人们在开始发出 javascript 请求时会回到 RPC 风格，考虑到 Javascript 的自然异步性，这很不幸.

This "state management" model can be very limiting, as your current application state is based on a single server response. However, complex applications can be built by using a set of user-agents working together. This is part of what AJAX achieves in that it allows a distinct user-agent to be used to make separate requests and therefore, in effect, manage another state machine. Unfortunately, most of the time people resort back to an RPC style when they start making javascript requests, which is unfortunate considering the natural asynchrony of Javascript.

这篇关于HATEOAS:简明描述的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！