单页应用的HATEOAS实战

HATEOAS是Hypertext As The Engine Of Application State的缩写。在 Richardson Maturity Model中, 它是REST的最高级形态。

单页应用正越来越受到欢迎，前后端分离的开发模式进一步细化了分工，但同时也引入了不少重复的工作，例如一些业务规则在后端必须实现的情况下，前端也需要再实现一遍以获得更好的用户体验。HATEOAS虽然不是唯一消除这些重复的方法，但作为一种架构原则，它更容易让团队找到消除重复的“套路”。

什么是HATOEAS

HATEOAS是Hypertext As The Engine Of Application State的缩写。采用Hypermedia的API在响应(response)中除了返回资源(resource)本身外，还会额外返回一组Link。 这组Link描述了对于该资源，消费者(consumer)接下来可以做什么以及怎么做。

举例来说，假设向API发起一次get请求，获取指定订单的资源表述(representation)，那么它应该长得像这样：

HTTP/1.1 200 OK 

Server: Apache-Coyote/1.1 

Content-Type: application/hal+json;charset=UTF-8 

Transfer-Encoding: chunked 

Date: Fri, 05 Jun 2015 02:54:57 GMT 

{ 

  "tracking_id": "123456", 

  "status": "WAIT_PAYMENT", 

  "items": [ 

    { 

       "name": "potato", 

       "quantity": 1 

    } 

  ], 

  "_Links": { 

    "self": { 

      "href": ":57900/orders/123456" 

    }, 

    "cancel": { 

      "href": ":57900/orders/123456" 

    }, 

    "payment": { 

      "href": ":57900/orders/123456/payments" 

     } 

  } 

} 

理解Link中的“self”的消费者知道使用get方法访问其“href”的uri可以查看该订单的详细信息。

理解Link中的“cancel”的消费者知道使用delete方法访问其“href”的uri可以取消该订单。

理解Link中的“payment”的消费者知道使用post方法访问其“href”的uri可以为该订单付款。

REST是目前业界相当火热的术语，似乎发布的API不带个REST前缀，你都不好意思和别人打招呼了。 然而大部分号称REST的API实际上并没有达到Richardson成熟度模型的第三个级别：Hypermedia。 而REST的发明者Roy Fielding博士更是直言HATEOAS是REST的前提， 这不是一个可选项，如果没有Hypermedia，那就不是REST。(摘自Infoq对Fielding博士的第二段访谈)

那么HATOEAS带来了什么优势?

一个显而易见的好处是，只要客户端总是使用Link Rel来获取URI，那么服务端可以在不破坏客户端实现的情况下实现URI的修改，从而进一步解耦客户端和服务端。

另一个容易被忽视的优势是它可以帮助客户端开发者探索API，Links实际上提示了开发者接下来可以进行何种业务操作，开发者虽然精通技术，但往往对于业务不甚了解，这些提示可以帮助他们理解业务，至少是一个查询API文档的好起点。想象一下，如果某个API的响应中多了一个新的Link，敏感的开发者可能就会询问这个Link是用来做什么的，是一个新的特性吗?虽然看起不起眼，但这往往使两个团队的成员沟通起来更容易。

单页应用和HATEOAS

在过去的几年里，WEB开发技术发生了很多重大的变革，其中之一就是单页应用，它们往往能带来更平滑的用户体验。在这一领域，分工进一步细化，前端工程师专精客户端程序构建和HTML、CSS等效果的开发，后端工程师则更偏重高并发、DevOps等技能，大部分特性需要前后端工程师配合完成。