HATEOAS

HATEOAS = Hypermedia As The Engine Of Application State = 超媒体即应用状态引擎

谈到REST时，往往会提到这个HATEOAS。

什么是HATEOAS？

或者说：

• 为何会有HATEOAS？
• HATEOAS有什么好处或作用？

找个例子来比喻，就容易理解了：

举例解释HATEOAS

比如有个用户的对象，或者说资源，定义是：

class Customer {
    String name;
}

而普通的REST，GET后返回的信息是：

{
    "name" : "Alice"
}

而简单点的HATEOAS则返回是：

{
    "name": "Alice",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } ]
}

好处是：

客户端，不需要再去问提供了接口的服务器端，就可以通过此HATEOAS返回的信息中知道一些额外的信息：

• rel： 表示relationship关系。此处的self指的是就是对象Customer自己本身。
  • 而更加复杂点的情况中，可能会包含其他的对象，比如"rel":"customer"
• href：当前对象的完整的url地址。

由此可以看出：

如果后台接口支持，或者说实现了HATEOAS这套标准（规范），那么：

调用接口的前端（移动端等），就可以像：

用户通过点击页面的href的链接地址，而跳转到其他网页，实现浏览网页的过程了。

-> 让调用REST的api就可以实现，类似于用户浏览网页的从一个页面跳转到另外一个页面的过程了

-> 而这种超链接方式的api用于告诉用户：该资源的只允许哪些操作（比如GET,POST)，以及不允许哪些操作（比如DELETE）

-> 从而达到方便用户更加清楚使用你的接口的目的

其他HATEOAS实例

• Eve (Python)
• RESTHeart (Java)

关于HATEOAS的最佳实践：不用HATEOAS

但是HATEOAS的缺点也很明显：

就把简单的返回的信息，搞的更加复杂了。

也因此实际在开发REST的api过程中，至少我是很少采用这个规范的。

当然，也有和我持同样观点的，比如这位

-》这样会让前端解析API时，倒是变得更加复杂了。显得多此一举和增加复杂度了。

而之前自己在折腾选择好的Flask的REST API的框架期间，本来觉得eve不错，后来就是由于发现eve默认使用HATEOAS，把返回的json搞的太复杂，而放弃eve的。

顺带提及一点的是：

针对于HATEOAS标准，也还有是别人会用的。

所以一些流行的REST的框架中，有些也是内置支持了HATEOAS。

比如：Flask的REST框架：

• eve
• ripozo
• flask-marshmallow

另外，再贴出来一个复杂点的HATEOAS的例子，仅供了解：

{
    "content": [ {
        "price": 499.00,
        "description": "Apple tablet device",
        "name": "iPad",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/product/1"
        } ],
        "attributes": {
            "connector": "socket"
        }
    }, {
        "price": 49.00,
        "description": "Dock for iPhone/iPad",
        "name": "Dock",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/product/3"
        } ],
        "attributes": {
            "connector": "plug"
        }
    } ],
    "links": [ {
        "rel": "product.search",
        "href": "http://localhost:8080/product/search"
    } ]
}