單頁應用的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": "http://localhost:57900/orders/123456"
- },
- "cancel": {
- "href": "http://localhost:57900/orders/123456"
- },
- "payment": {
- "href": "http://localhost: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等技能，大部分特性需要前后端工程師配合完成。
或許有人會質疑，為什么不是全棧工程師?誠然，如果一個人就能端到端的交付特性，那自然會減少溝通成本，但全棧工程師可不好找，細化分工才能適應規模化的開發模式。繼Ajax之后，單頁應用和前后端分離架構進一步催生了大量的API，我們急需一些方法來管理這些API的開發和演進，而HATEOAS應該在此占有一席之地。
在摸索中前進，自由地重命名你的資源
我們常說在敏捷開發中，應該擁抱變化。所以敏捷開發中推崇重構、單元測試、持續集成等技術，因為它們可以使變化更容易、更安全。HATOEAS也是這樣一種技術。想象一下，在項目初始階段，團隊對業務的理解還不深入，很有可能會得出錯誤的業務術語命名，或者業務對象的建模也不完全合適。反映在API上，可能你希望能夠修正API的URI，在非HATOEAS的項目中，由于URI是在客戶端硬編碼的，即使你把它們設計的非常漂亮(準確的HTTP動詞，以復數命名的資源，禁止使用動詞等等)，也不能幫助你更容易地修改它們，因為你的重構需要前端開發者的配合，而他/她不得不停下手頭的其他工作。
但在采用了HATEOAS的項目中，這很容易，因為客戶端是通過Link來查找API的URI，所以你可以在不破壞API Scheme的情況下修改它的URI。當然，你不可能保證所有API的URI都是通過Link來獲取的，你需要安排一些Root Resource，例如 /api/currentLoggedInUser，否則客戶端沒有辦法發起***次請求。
- HTTP/1.1 200 OK
- Path: /api/currentLoggedInser (1)
- {
- …… //omitted content
- "_Links": { (2)
- "searchUserStories": {
- "href": "http://localhost:8080/userStories/search{?page, size}"
- },
- "searchUsers": {
- "href": "http://localhost:8080/users/search{?page, size, username}"
- },
- "logout": {
- "href": "http://localhost:8080/logout"
- }
- }
- }
- Root Resource，它們是API的入口，客戶端通過他們瀏覽當前用戶有哪些資源可以訪問，你可以定義多個Root Resource，并確保它們的URI不會改變
- Link引入的URI可以自由地變化，可能是因為需要重命名資源，也可能是需要抽取出新的服務(域名變化)
消除重復的業務規則校驗實現，更容易得適應變化
經驗告訴我們，不能相信客戶端的請求，所以在服務端我們需要根據業務規則校驗當前的請求是否合法。這樣確保了業務正確，但當用戶發起了請求后才告訴他們請求失敗，有時候是一件令人沮喪的事情。為了用戶體驗，可能會要求某些組件根據業務規則展示。例如，對于某個業務對象，要求編輯按鈕只在當前用戶可以編輯的情況下才展示。在傳統的服務端渲染架構下，一般都可以復用校驗的代碼，而在單頁應用中，往往由于技術棧不同，代碼無法直接共用，業務規則在前后端都分別實現了一次。例如，在我們最近的一次項目中，前后端分別實現了如下規則：
- 給定一個用戶故事
- 只有它的作者才能編輯它
服務端通過在用戶故事的API中暴露作者幫助前端完成編輯按鈕的有條件渲染。
- HTTP/1.1 200 OK
- Path: /api/userStories/123
- {
- "author": "john.doe@gmail.com" (1)
- }
1. 與當前用戶比較判斷是否渲染編輯按鈕
但如果規則發生變化，前后端都需要適應這一改變，所以我們用HATEOAS重構了一下：
- HTTP/1.1 200 OK
- Path: /api/userStories/123
- {
- "author": "john.doe@gmail.com",
- "_links": {
- "updateUserStory": {
- "href": "http://localhost:8080/api/userStories/123" (1)
- }
- }
- }
2. 現在前端會根據 updateUserStory link是否出現來驗證當前用戶是否具有編輯用戶故事的能力
后來業務規則變為除了作者之外，系統管理員也可以編輯用戶故事，這時候只需要后端去響應這個變化就行了。你可能會質疑，通過為用戶故事暴露一個 isCurrentLoggedInUserAvailableToUpdate的計算屬性也可以做到。沒錯，HATOEAS并不是唯一的辦法，但作為一種架構約束，團隊會自然而然地想到它，而計算屬性則要求團隊成員有更強的抽象技能。
總結
HATEOAS提倡在響應返回Link來提示對該資源接下來的操作。這種方式解耦了服務端URI，也可以讓客戶端開發者更容易地探索API。***，通過Link來判斷業務狀態，還能有效地消除單頁應用中的業務規則重復實現。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
