今天听到两个同学找我，说想试试HATEOAS，方便通过晋升答辩，被我严词拒绝。任何针对晋升的技术选型，都是耍流氓。
殊不知，HATEOAS，正是行业大拿Roy Fielding在他的博士论文里搞出来的东西。
画外音：假装幽默。
Roy Fielding，何许人也？
计算机科学家，架构师，HTTP协议核心设计者，Apache Web Server核心作者，REST之父。
什么是REST？
REST（Representational
State Transfer），（资源）表现层状态转移，由Roy Fielding提出，它是一种满足一定约束条件的前端架构风格。
资源表现层状态转移，这个架构风格中有一些核心要素：
（1）资源（Resource）：可以理解为数据，用户数据，订单数据，支付数据等；
（2）表现层（Representational）：资源的表现形式，JSON，XML等；
（3）状态转移（State Transfer）：资源状态变化，增删查改；
我们常说的RESTful风格架构，其核心是面向资源的架构（Resource-Oriented Architecture），通过HTTP协议的具体化实践，可以这么理解：
（1）资源通过URI来标识，通过URI的访问来实现资源的互动；
（2）对资源的增删查改状态转移，通过HTTP的POST/DELETE/GET/PUT方法来指定；
（3）资源的表现形式，通过HTTP请求头中的Accept和Content-Type来指定；
举例，这是一个RESTful风格的接口：
GET abc.com/account/shenjian
{
"result": "OK",
"data": {
"name": "shenjian",
"uid": "1234",
"money": "100"
}
}
反例，这不是一个RESTful风格的接口：
POST abc.com/update/account/1234
{
"money": "80"
}
画外音：修改操作，却用了POST方法。
可以看到，RESTful的URI中，一般没有get/del/update等这些动词，资源的状态转移，是通过HTTP的方法来描述的。
画外音：当然，很多人在设计URI的过程中，也没有认真考虑这些规范，觉得这是强迫症。
什么是HATEOAS？
HATEOAS（Hypertext As The
Engine Of Application State），也是Roy Fielding提出的，是一种更高成熟度的RESTful架构风格，超文本作为应用状态的引擎。
画外音：好拗口。
其特点是：
（1）一个资源访问的返回结果中，包含该资源相关联的操作信息；
（2）无需在前端中硬编码资源的相关操作，降低前端复杂性，使得前端代码更具备扩展性，更容易维护，减少对API文档的依赖；
画外音：好抽象。
举个具体的例子，大家就明白了。前文中的例子，获取用户余额接口，返回了用户的余额100元。
GET abc.com/account/shenjian
站在业务的角度想想看，用户获取了余额，后续可能会干嘛呢？存钱、取钱、转账...HATEOAS要求通过links直接返回潜在的URI关联操作：GET abc.com/account/shenjian"href": "abc.com/account/1234/deposit""href": "abc.com/account/1234/withdraw""href": "abc.com/account/1234/transfer"
但获取用户余额接口，如果用户的余额是-100元，此时用户只能继续存钱，无法取钱和转账，那么返回的内容就会有所不同：GET abc.com/account/shenjian"href": "abc.com/account/1234/deposit"
在返回资源数据的同时，还带上了该资源在这种状态下的潜在操作，降低前端架构的复杂性，提高前端架构的扩展性。HATEOAS是一种站在前端的角度，理想化的前端引擎：（1）它极大的增加了后端的复杂性，同一个接口，后端需要理解返回的数据的业务含义，来决定增加哪些资源操作的URI；（2）原本单纯的后端资源访问接口，变得与业务逻辑耦合。画外音：我返回余额就好了，为什么要理解-100，0，100，1000的业务数据含义？而且，这种理想化的“完备性”，与目前流行各种轻量级前端框架理念（React，Angular等）相违背，与快速开发快速迭代的简化API设计理念相违背，几乎没有工具与框架支持。
