HATEOAS：简洁的描述
我试图对 HATEOAS 有一个清晰、简洁的理解，而且我绝不是 WRT REST 专家。 （我想我明白了，感谢这个 http://www.looah.com/source/查看/2284）。
谁能推荐一篇同样有启发性的博客/文章 WRT HATEOAS？
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 ).
Can anyone suggest an equally enlighenting blog/article WRT HATEOAS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
超媒体约束（以前称为 HATEOAS）是用于向用户代理提供方向的约束。
通过在返回的表示中包含链接，服务器可以消除用户代理的负担，即根据当前应用程序状态确定可以采取哪些操作并了解与谁交互以实现该目标目标。
由于服务器除了在请求中接收到的内容之外不知道用户代理的当前状态，因此用户代理尝试避免使用除从服务器返回的表示形式之外的状态非常重要。这确保服务器提供的可用操作尽可能基于对用户代理状态的最完整理解。
符合超媒体约束的用户代理就像一个状态机，其中状态转换是由当前表示中可用的链接引起的。返回的表示成为新状态。
这种方法的好处是可以实现非常轻量级的用户代理。它只需要很少的代码来管理状态，因为它的操作应该纯粹基于收到的响应和检索该响应的链接。 用户代理代码变得声明性和反应性，而不是 GET this then do this 然后 do that 的命令式序列，您只需具有跟踪链接和许多 WHEN you receive this THEN do that 的实例的机制。
要了解其工作原理的示例，您只需查看网络浏览器和不使用 Javascript 的网站即可。浏览器会根据 HTML 中的链接向您提供选项。当您点击该链接时，浏览器会将其当前状态替换为您点击该链接时检索到的新状态。后退按钮有效（或至少应该），因为您正在从历史记录中的链接检索状态。浏览器不应该关心您如何到达页面，因为状态应该完全基于检索到的表示。
这种“状态管理”模型可能非常有限，因为您当前的应用程序状态基于单个服务器响应。但是，可以通过使用一组协同工作的用户代理来构建复杂的应用程序。这是 AJAX 实现的一部分，因为它允许使用不同的用户代理来发出单独的请求，因此实际上管理另一个状态机。不幸的是，大多数时候人们在开始发出 javascript 请求时都会诉诸 RPC 风格，考虑到 Javascript 的自然异步性，这是不幸的。
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.
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.
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.
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 简而言之：在您输出的数据中，使用 URI 而不是 ID 来引用其他资源。
由于所有简短的定义，我刚刚给出的定义在很多层面上都是错误的，但它应该让您了解 HATEOAS 的关键是什么。
现在，进行更长一点的解释。
HATEOAS 原则指出应用程序的状态应该通过超文本链接前进。想象一下您在互联网上浏览的情况。首先，您必须在地址栏中输入地址。从那时起，您的导航进步几乎仅归功于对链接的点击：您点击链接，最终会进入另一个页面。再单击一次，此处会出现另一个页面。浏览器如何将您从第一页移动到第二页到第三页？它使用
元素中编码的 URL。同样，如果您的 REST 应用程序生成此结果
，则接收应用程序无需访问任何外部知识源即可知道第一家酒店位于
http://example/hotel/0928374，第二家酒店位于http://example/hotel/0928374一个位于http://example/guest-h/7082。另一方面，如果您的应用程序生成带有 ID 的响应，则
接收应用程序必须提前知道 ID 必须如何与前缀组成，才能获取每个住宿信息可用的 URI（例如 "add
http://example/到每个请求，然后为酒店添加hotel并为宾馆添加guest-h”）。您可以看到，这种机制与许多数据库应用程序中发生的情况类似，但与浏览器的工作方式不同。遵循 HATEOAS 原则非常重要，因为它允许应用程序在不大幅更改接收应用程序的情况下增长。假设您想要更改
http://example.com/hotel/ 中的 URI 0928374 至https://reviews.example.com/accommodation/0928374。如果您遵循 HATEOAS，这将是一个简单的更改：修改返回的值，并且它是：接收应用程序将继续工作而无需任何修改。相反，如果您有关于如何构造 URI 的单独文档，则您将必须联系所有应用程序开发人员并要求他们注意文档已更新，并且他们应该更改代码以反映更改。免责声明：这是一个快速回答，仅触及问题的表面。但如果你明白了这一点，你就掌握了 80% 的 HATEOAS 原则。
HATEOAS in few words: In the data you output, refer to other resources using URIs, not IDs.
As all the short definitions, the definition I just gave is wrong on many levels, but it should make you understand what the crux of HATEOAS is.
Now, for a bit longer explaination.
The HATEOAS principle says that the state of your application should advance through hypertext links. Think of you browsing around the internet. First you have to type an address in the address bar. From that point on, your navigation advances pretty much only thanks to clicks on links: you click on a link and you end up on another page. Another click and here appears another page. How was the browser able to move you from the first page to the second to the third? It used the URLs encoded in
<a>elements.Similarly if your REST applications generates this result
then the receiving application will not have to access any external sources of knowledge to know that the first hotel is available at
http://example/hotel/0928374and the second one athttp://example/guest-h/7082.On the other hand, if your application generates responses with IDs like
the receiving application will have to know in advance how IDs must be composed with prefixes to get the URI at which the information for each accommodation is available (for example "add
http://example/to every request, then addhotelfor hotels andguest-hfor guest houses"). You can see that this mechanism is similar to what happens in many DB applications but is different from how browsers work.It is important to follow the HATEOAS principle because it allows applications to grow without drastic changes to the receiving applications. Suppose you want to change your URIs from
http://example.com/hotel/0928374tohttps://reviews.example.com/accommodation/0928374. If you followed HATEOAS is would be a simple change: modify the returned values and that it is: receiving applications will continue to work without any modification. If instead you had separate documentation for how to construct URI, you will have to contact all the application developers and ask them to notice that the documentation has been updated and they should change their code to reflect the changes.Disclaimer: this is a quick answer that just scratches the surface of the problem. But if you get this you got 80% of the HATEOAS principle.
这篇文章帮助我彻底理解了它。 http://restcookbook.com/Basics/hateoas/
它简单而优雅。
HATEOAS 代表作为应用程序状态引擎的超文本。这意味着应该使用超文本来查找 API 的路径。举个例子：
除了我们的账户中有 100 美元（美元）这一事实之外，我们还可以看到 4 个选项：存入更多资金、提款、将资金转移到另一个账户或关闭我们的账户。 “link”标签使我们能够找到指定操作所需的 URL。现在，假设我们银行里没有 100 美元，但我们实际上亏损了：
现在我们亏损了 25 美元。你看现在我们失去了很多选择，只有存钱才有效吗？只要我们处于亏损状态，我们就无法关闭账户，也无法从账户中转账或提取任何资金。超文本实际上告诉我们什么是允许的，什么是不允许的：HATEOAS
This article helped me to understand it thoroughly. http://restcookbook.com/Basics/hateoas/
It is simple and elegant.
HATEOAS stands for Hypertext As The Engine Of Application State. It means that hypertext should be used to find your way through the API. An example:
Apart from the fact that we have 100 dollars (US) in our account, we can see 4 options: deposit more money, withdraw money, transfer money to another account, or close our account. The "link"-tags allow us to find out the URLs that are needed for the specified actions. Now, let's suppose we didn't have 100 USD in the bank, but we actually are in the red:
Now we are 25 dollars in the red. Do you see that right now we have lost many of our options, and only depositing money is valid? As long as we are in the red, we cannot close our account, nor transfer or withdraw any money from the account. The hypertext is actually telling us what is allowed and what not: HATEOAS
REST 和 REST 的一个问题HATEOAS 是困难以及缺乏对接口定义的可见性和控制。对于更传统的 RPC 风格的交互，通常有一个人工制品，例如定义 API 的 IDL 或 WSDL，并且可以由项目控制和管理。
使用 HATEOAS，API 是动态可发现的，并且可以将其描述为一组行为（状态更改）。代码中描述了这些行为。 API 描述 (WADL) 是从代码生成的，而不是从接口描述生成的代码。
One issue with REST & HATEOAS is the difficulty and lack of visibility and control over the interface definition. With more traditional RPC style interaction there was usually an artefact such as an IDL or WSDL that defined the API and could be controlled and managed by the project.
With a HATEOAS the API is dynamically descoverable and it may be described as a set of behaviours (state changes). The behaviours are described in the code. The API description (WADL) is generated from the code rather than code being generated from the interface description.
从我个人使用 HATEOAS 引擎的经验来看，最大的区别在于设计本身的理念。
如果我们要构建一个 Web 应用程序，有两种方法。一种是 RPC 风格，另一种是 REST 风格。
如果必须以 RPC 方式测试状态，我们需要调用返回结果的 RPC 过程。采用这种设计方法，第一次调用后返回的参数必须存储在客户端，以便后续调用可以使用返回的参数。这只是使客户端和服务器紧密耦合，使整个系统具有状态。
而在 REST 风格中，没有 RPC。重要的是客户端和服务器之间的交互。对于任何状态转换，客户端都必须与服务器交互以获取信息。唯一固定的交互是家庭交互。其余的都是客户在经历不同的交互时发现的。
从计算机科学的角度来看，一种是程序风格，一种是算法风格。其中 REST 风格是一种交互范例。任何采用交互范式作为语言的系统都将提供 HATEOAS 系统。
From my personal experience working with a HATEOAS engine, the biggest difference is the philosophy of the design itself.
If we are going to build a web application there are two approaches for it. One is the RPC Style and the other is the REST Style.
If state has to be tested in a RPC style we need to call a RPC procedure which returns a result. With such an design approach, parameters returned after the first call has to be stored on the client so that further calls can use the parameters that were returned. This simply makes the client and server tightly coupled, making the overall system stateful.
Whereas in the REST style, there is no RPC. What matters is the interactions between the client and the server. For any transition of state, the client has to interact with the server to get information. The only interaction that is fixed is the home interaction. The rest are all discovered by the client as it goes through the different interactions.
From a computer science perspective, one is procedural style and it is algorithmic. where as the REST style is a interactional paradigm. Any system that adopts interactional paradigm as the language would be delivering a HATEOAS system.