Question

我试图对HATEOAS有一个清晰而简洁的理解，我绝不是专家WRT REST。（我想我得到了它，感谢这个http://www.looah.com/source/view/2284）。

任何人都可以建议一个同样令人敬畏的博客/文章WRT HATEOAS吗？

Answer 1

超媒体约束（以前称为HATEOAS）是一种用于为用户代理提供方向的约束。

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

由于服务器不了解用户代理的当前状态而不知道它在请求中收到的状态，因此用户代理尝试避免使用除服务器返回的表示之外的状态非常重要。这可确保服务器提供的可用操作基于对用户代理状态的最完整理解。

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

此方法的好处可能是非常轻量级用户代理。它需要很少的代码来管理状态，因为它的操作应该完全基于接收的响应和检索该响应的链接。 用户代理代码变为声明性和被动，而不是GET的命令性序列然后执行此操作，然后执行此操作，您只需拥有跟踪链接的机制以及当您收到此链接的许多实例时那么这样做

对于示例的工作方式，您只需要浏览网页浏览器和不使用Javascript的网站。浏览器根据HTML中的链接为您提供选项。当您按照该链接时，浏览器会将当前状态替换为您在跟踪链接时检索到的新状态。后退按钮有效（或至少应该），因为您正在从历史记录中的链接中检索状态。浏览器不应该关心你如何访问页面，因为状态应该完全基于检索到的表示。

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

Answer 2

HATEOAS用几句话来说：在您输出的数据中，使用URI而不是ID来引用其他资源。

作为所有简短的定义，我刚给出的定义在很多层面都是错误的，但是它应该让你明白HATEOAS的关键是什么。

现在，需要更长时间的解释。

HATEOAS原则指出，您的应用程序的状态应该通过超文本链接进行。想想你在互联网上浏览。首先，您必须在地址栏中键入地址。从那时起，只需点击链接，您的导航就会前进：您点击一个链接，然后最终进入另一个页面。另一次点击，这里出现另一页。浏览器如何将您从第一页移到第二页再到第三页？它使用<a>元素中编码的URL。

同样，如果您的REST应用程序生成此结果

<accomodation>
  <hotel info="http://example/hotel/0928374" price="200"/>
  <guest-house info="http://example/guest-h/7082" price="87"/>
</accomodation>

然后，接收应用程序将无需访问任何外部知识来源，即知道第一家酒店位于http://example/hotel/0928374，第二家位于http://example/guest-h/7082。

另一方面，如果您的应用程序生成ID为

的响应

<accomodation>
  <hotel id="0928374" price="200"/>
  <guest-house id="7082" price="87"/>
</accomodation>

接收应用程序必须事先知道ID必须如何与前缀组合才能获得每个住宿信息可用的URI（例如“添加http://example/到每个请求，然后为酒店添加hotel，为招待所添加guest-h“）。您可以看到此机制与许多数据库应用程序中发生的情况类似，但与浏览器的工作方式不同。

遵循HATEOAS原则非常重要，因为它允许应用程序在不对接收应用程序进行重大更改的情况下增长。假设您要将URI从http://example.com/hotel/0928374更改为{{1} }。如果您遵循HATEOAS将是一个简单的更改：修改返回的值并且它是：接收应用程序将继续工作而不进行任何修改。如果您有关于如何构造URI的单独文档，则必须联系所有应用程序开发人员并要求他们注意文档已更新，并且他们应该更改其代码以反映更改。

免责声明：这是一个快速回答，只是触及问题的表面。但如果你得到这个，你就得到了HATEOAS原则的80％。

Answer 3

REST＆amp; amp; HATEOAS是界面定义的难点和缺乏可见性和控制。通过更传统的RPC样式交互，通常会有一个诸如IDL或WSDL之类的人工制品来定义API，并且可以由项目进行控制和管理。

使用HATEOAS，API是动态可解除的，可以将其描述为一组行为（状态更改）。行为在代码中描述。 API描述（WADL）是从代码生成的，而不是从接口描述生成的代码。

Answer 4

这篇文章帮助我彻底理解了它。 http://restcookbook.com/Basics/hateoas/

简单而优雅。

HATEOAS代表超文本作为应用程序状态引擎。这意味着应该使用超文本来找到通过API的方式。一个例子：

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">100.00</balance>
    <link rel="deposit" href="/account/12345/deposit" />
    <link rel="withdraw" href="/account/12345/withdraw" />
    <link rel="transfer" href="/account/12345/transfer" />
    <link rel="close" href="/account/12345/close" />
</account>

除了我们在帐户中有100美元（美国）这一事实外，我们还可以看到4种选择：存入更多资金，取款，转账到其他帐户或关闭我们的帐户。＆＃34;链接＆＃34; -tags允许我们找出指定操作所需的URL。现在，让我们假设我们银行没有100美元，但我们实际上是红色的：

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">-25.00</balance>
    <link rel="deposit" href="/account/12345/deposit" />
</account>

现在我们红了25美元。你现在看到我们失去了很多选择吗？只有存钱才有效吗？只要我们处于亏损状态，我们就无法关闭账户，也无法转账或从账户中提取任何款项。超文本实际上告诉我们什么是允许的，什么不是：HATEOAS

Answer 5

根据我使用HATEOAS引擎的个人经验，最大的区别在于设计本身的理念。

如果我们要构建一个Web应用程序，有两种方法可供选择。一个是RPC样式，另一个是REST样式。

如果必须以RPC样式测试状态，我们需要调用返回结果的RPC过程。使用这种设计方法，第一次调用后返回的参数必须存储在客户端上，以便进一步调用可以使用返回的参数。这简单地使客户端和服务器紧密耦合，使整个系统有状态。

而在REST样式中，没有RPC。重要的是客户端和服务器之间的交互。对于任何状态转换，客户端必须与服务器交互以获取信息。唯一固定的互动是家庭互动。其余的都是客户发现的，因为它经历了不同的互动。

从计算机科学的角度来看，一个是程序风格，它是算法。 REST风格是一种互动范式。任何采用交互范式作为语言的系统都将提供HATEOAS系统。

HATEOAS：简洁的描述

5 个答案: