HATEOAS：简洁的描述
我试图对HATEOAS有一个清晰和简明的理解，而我绝不是一个专家WRT REST（我认为我明白了，这要感谢http://tomayko.com/writings/rest-to-my-妻子）
任何人都可以提出一个同样令人生气的博客/文章WRT HATEOAS？
超媒体约束（以前称为HATEOAS）是一种约束，用于为用户代理提供指导。
通过在返回的表示中包含链接，服务器可以从用户代理中移除确定可以基于当前应用程序状态采取什么操作并知道为了实现该目标而进行交互的人员的负担。
由于服务器不知道用户代理的当前状态，而不是它在请求中接收到的状态，所以用户代理尝试避免使用除服务器返回的表示以外的状态很重要。 这确保服务器提供的可用操作基于对用户代理状态的最完整理解。
符合超媒体约束的用户代理就像状态机，其状态转换是由当前表示中可用的后续链接引起的 。 返回的表示成为新状态。
这种方法的好处可以是一个非常轻量级的用户代理 。 它只需要很少的代码来管理状态，因为它的行为应该完全基于接收到的响应和检索该响应的链接。 用户代理代码变成声明式和反应式的，而不是GET的命令序列，然后做到这一点，然后做到这一点，你只需拥有以下链接的机制和许多当你收到这个时候这样做的实例。
有关如何工作的示例 ，您只需浏览网页浏览器和不使用Javascript的网站。 浏览器为您提供基于HTML链接的选项。 当你关注这个链接时，浏览器用你在链接中检索到的新状态替换它的当前状态。 后退按钮起作用（或者至少应该），因为您正在从历史记录中的链接中检索状态。 浏览器不应该关心你如何进入页面，因为状态应该完全基于检索到的表示。
这种“状态管理”模式可能非常有限 ，因为您当前的应用程序状态基于单个服务器响应。 但是， 可以通过使用一组用户代理一起工作来构建复杂的应用程序 。 这是AJAX实现的一部分，因为它允许使用不同的用户代理进行单独的请求，因此实际上可以管理另一个状态机。 不幸的是，大多数时候人们在开始制作javascript请求时会回到RPC风格，这不幸考虑到Javascript的自然异步。
HATEOAS用几句话说： 在输出的数据中，使用URI来引用其他资源，而不是ID。
正如所有简短的定义一样，我刚才给出的定义在许多层面都是错误的，但它应该让你明白HATEOAS的核心是什么。
现在，再稍微解释一下。
HATEOAS原则规定，应用程序的状态应通过超文本链接提前。 想想你在网上浏览。 首先你必须在地址栏中输入一个地址。 从那时起，您的导航几乎只会感谢点击链接：您点击一个链接，然后最终进入另一个页面。 再点击一下，出现另一页。 浏览器如何将您从第一页移动到第二页到第三页？ 它使用<a>元素编码的网址。
同样，如果您的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/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/ to each request，then add hotel for hotels and guest-h for guest houses“）。 您可以看到，这种机制与许多DB应用程序中发生的情况类似，但与浏览器的工作方式不同。
遵循HATEOAS原则很重要，因为它允许应用程序在不对接收应用程序进行重大更改的情况下发展。 假设您想将您的URI从http://example.com/hotel/0928374更改为https://reviews.example.com/accommodation/0928374 。 如果你遵循HATEOAS，将会是一个简单的改变：修改返回的值，它是：接收应用程序将继续工作，无需任何修改。 相反，如果您有关于如何构建URI的单独文档，则必须联系所有应用程序开发人员，并要求他们注意文档已更新，他们应更改其代码以反映更改。
免责声明：这是一个快速回答，只是抓住了问题的表面。 但是，如果你得到这个，你有80％的HATEOAS原则。
REST和HATEOAS的一个问题是界面定义的难度和缺乏可见性和控制。 使用更传统的RPC式交互时，通常会有一个人工制品（如IDL或WSDL）来定义API，并且可以由项目进行控制和管理。
使用HATEOAS，API是动态可解析的，可以将其描述为一组行为（状态更改）。 行为在代码中描述。 API描述（WADL）是从代码生成的，而不是从接口描述生成的代码。
链接地址: http://www.djcxy.com/p/7019.html