简述HATEOAS

HATEOAS（Hypermedia as the engine of application state）是 REST 架构风格中最复杂的约束，也是构建成熟 REST 服务的核心。它的重要性在于打破了客户端和服务器之间严格的契约，使得客户端可以更加智能和自适应，而 REST 服务本身的演化和更新也变得更加容易。

在介绍 HATEOAS 之前，先介绍一下 Richardson 提出的 REST 成熟度模型。该模型把 REST 服务按照成熟度划分成 4 个层次：

第一个层次（Level 0）的 Web 服务只是使用 HTTP 作为传输方式，实际上只是远程方法调用（RPC）的一种具体形式。SOAP 和 XML-RPC 都属于此类。
第二个层次（Level 1）的 Web 服务引入了资源的概念。每个资源有对应的标识符和表达。
第三个层次（Level 2）的 Web 服务使用不同的 HTTP 方法来进行不同的操作，并且使用 HTTP 状态码来表示不同的结果。如 HTTP GET 方法来获取资源，HTTP DELETE 方法来删除资源。
第四个层次（Level 3）的 Web 服务使用 HATEOAS。在资源的表达中包含了链接信息。客户端可以根据链接来发现可以执行的动作。
从上述 REST 成熟度模型中可以看到，使用 HATEOAS 的 REST 服务是成熟度最高的，也是推荐的做法。对于不使用 HATEOAS 的 REST 服务，客户端和服务器的实现之间是紧密耦合的。客户端需要根据服务器提供的相关文档来了解所暴露的资源和对应的操作。当服务器发生了变化时，如修改了资源的 URI，客户端也需要进行相应的修改。而使用 HATEOAS 的 REST 服务中，客户端可以通过服务器提供的资源的表达来智能地发现可以执行的操作。当服务器发生了变化时，客户端并不需要做出修改，因为资源的 URI 和其他信息都是动态发现的。

HATEOAS简介_xinyue_htx的博客-CSDN博客

简述HATEOAS_Legend never die的博客-CSDN博客

什么是HATEOAS

HATEOAS是Hypermedia as the Engine of Application State的缩写。

翻译过来就是超媒体即应用状态引擎。

那这个是什么样的一个东西呢？

我们先来看一个现实中的问题。

问题来源

我们在项目开发中经常需要涉及同后端对接API。

对接的过程一般都是后端的同学给出一个文档，告诉我们有哪些API，可以获得什么样子的参数。

试想一下，如果有一天后端同学新增加了API，但是没有给这个API文档，那你该怎么办？

所以说API文档，成为了前后端对接的耦合因素。

HATEOAS解决什么问题

HATEOAS通过超媒体来提供客户端与服务器之间的交互。

即客户端可以通过一个简单的初始URI，并从返回值获取可以操作的其他信息。

这样一来，我们对接后端时，就几乎不需要额外的信息。

可以进一步实现前后端的解耦。

在Richardson Maturity Model中，HATEOAS为于最高层，可以显著提升RESTful API的可发现性和响应的自解释性。

HATEOAS例子

说了这么多大家可能还不是很了解，这里我们举个例子。

假设我们有这么一个API，可以返回一个人和他孩子的名字。

GET /people/huangtengxiao

<person>
    <name>huangtengxiao</name>
    <children>
        <name>xiaohuang</name>
    </children>
</person>

 

那按照RESTfulAPI的方式，我们可以通过POST方法给他添加孩子