HATEOAS:简洁的描述

Myl*_*ell 51 rest hateoas

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

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

Dar*_*ler 62

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

通过在返回的表示中包括链接,服务器可以消除用户代理的负担,即基于当前应用状态确定可以采取什么动作并且知道谁与按顺序交互以实现该目标.

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

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

这种方法的好处可以是非常轻量级的用户代理.它需要很少的代码来管理状态,因为它的操作应该完全基于接收的响应和检索该响应的链接.该用户代理代码变得声明和反应,而不是得到这个那么做的必要序列,然后做到这一点,你只需有以下链接和许多情况下的机制,当你收到此THEN做到这一点.

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

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

  • @MylesMcDonnell Mike Amundsen有很多帖子涵盖了这个主题http://www.amundsen.com/blog/archives/?category=22 (3认同)
  • @DarrelMiller:如果我理解正确的话,如果遵守 HATEOAS 约束,应用程序可能的有限转换状态将绑定到当前表示中的 **links**。缺什么吗? (2认同)
  • @PK'这似乎是一个体面的概要. (2认同)

gio*_*ele 47

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>
Run Code Online (Sandbox Code Playgroud)

那么接收应用程序将不必访问任何外部知识来源,以便知道第一家酒店可用,http://example/hotel/0928374第二家酒店位于http://example/guest-h/7082.

另一方面,如果您的应用程序生成带有ID的响应

<accomodation>
  <hotel id="0928374" price="200"/>
  <guest-house id="7082" price="87"/>
</accomodation>
Run Code Online (Sandbox Code Playgroud)

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

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

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

  • @MylesMcDonnell我认为HATEOAS中固有的问题是你不能强迫客户使用它.没有什么可以阻止客户端在其客户端应用程序中硬编码URI结构.没有什么可以阻止他们根据他们对URI空间的假设来构建自己的URI.没有什么可以阻止他们假设,因为今天的响应提供媒体类型X它将始终返回媒体类型X.HATEOAS是客户端和服务器之间的合同,客户端可以轻松破解. (4认同)

ero*_*a84 5

这篇文章帮助我彻底理解了它。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>
Run Code Online (Sandbox Code Playgroud)

除了我们的帐户中有 100 美元(美元)这一事实之外,我们还可以看到 4 个选项:存入更多资金、取款、将资金转移到另一个帐户或关闭我们的帐户。“link”标签使我们能够找到指定操作所需的 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>
Run Code Online (Sandbox Code Playgroud)

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