單頁應(yīng)用的HATEOAS實戰(zhàn)
要點
HATEOAS是Hypertext As The Engine Of Application State的縮寫。在 Richardson Maturity Model中, 它是REST的***級形態(tài)。
單頁應(yīng)用正越來越受到歡迎，前后端分離的開發(fā)模式進(jìn)一步細(xì)化了分工，但同時也引入了不少重復(fù)的工作，例如一些業(yè)務(wù)規(guī)則在后端必須實現(xiàn)的情況下，前端也需要再實現(xiàn)一遍以獲得更好的用戶體驗。HATEOAS雖然不是唯一消除這些重復(fù)的方法，但作為一種架構(gòu)原則，它更容易讓團(tuán)隊找到消除重復(fù)的“套路”。
什么是HATOEAS
HATEOAS是Hypertext As The Engine Of Application State的縮寫。采用Hypermedia的API在響應(yīng)(response)中除了返回資源(resource)本身外，還會額外返回一組Link。 這組Link描述了對于該資源，消費(fèi)者(consumer)接下來可以做什么以及怎么做。
舉例來說，假設(shè)向API發(fā)起一次get請求，獲取指定訂單的資源表述(representation)，那么它應(yīng)該長得像這樣：
- 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”的消費(fèi)者知道使用get方法訪問其“href”的uri可以查看該訂單的詳細(xì)信息。
- 理解Link中的“cancel”的消費(fèi)者知道使用delete方法訪問其“href”的uri可以取消該訂單。
- 理解Link中的“payment”的消費(fèi)者知道使用post方法訪問其“href”的uri可以為該訂單付款。
REST是目前業(yè)界相當(dāng)火熱的術(shù)語，似乎發(fā)布的API不帶個REST前綴，你都不好意思和別人打招呼了。 然而大部分號稱REST的API實際上并沒有達(dá)到Richardson成熟度模型的第三個級別：Hypermedia。 而REST的***Roy Fielding博士更是直言HATEOAS是REST的前提， 這不是一個可選項，如果沒有Hypermedia，那就不是REST。(摘自Infoq對Fielding博士的第二段訪談)
那么HATOEAS帶來了什么優(yōu)勢?
一個顯而易見的好處是，只要客戶端總是使用Link Rel來獲取URI，那么服務(wù)端可以在不破壞客戶端實現(xiàn)的情況下實現(xiàn)URI的修改，從而進(jìn)一步解耦客戶端和服務(wù)端。
另一個容易被忽視的優(yōu)勢是它可以幫助客戶端開發(fā)者探索API，Links實際上提示了開發(fā)者接下來可以進(jìn)行何種業(yè)務(wù)操作，開發(fā)者雖然精通技術(shù)，但往往對于業(yè)務(wù)不甚了解，這些提示可以幫助他們理解業(yè)務(wù)，至少是一個查詢API文檔的好起點。想象一下，如果某個API的響應(yīng)中多了一個新的Link，敏感的開發(fā)者可能就會詢問這個Link是用來做什么的，是一個新的特性嗎?雖然看起不起眼，但這往往使兩個團(tuán)隊的成員溝通起來更容易。
單頁應(yīng)用和HATEOAS
在過去的幾年里，WEB開發(fā)技術(shù)發(fā)生了很多重大的變革，其中之一就是單頁應(yīng)用，它們往往能帶來更平滑的用戶體驗。在這一領(lǐng)域，分工進(jìn)一步細(xì)化，前端工程師專精客戶端程序構(gòu)建和HTML、CSS等效果的開發(fā)，后端工程師則更偏重高并發(fā)、DevOps等技能，大部分特性需要前后端工程師配合完成。
或許有人會質(zhì)疑，為什么不是全棧工程師?誠然，如果一個人就能端到端的交付特性，那自然會減少溝通成本，但全棧工程師可不好找，細(xì)化分工才能適應(yīng)規(guī)模化的開發(fā)模式。繼Ajax之后，單頁應(yīng)用和前后端分離架構(gòu)進(jìn)一步催生了大量的API，我們急需一些方法來管理這些API的開發(fā)和演進(jìn)，而HATEOAS應(yīng)該在此占有一席之地。
在摸索中前進(jìn)，自由地重命名你的資源
我們常說在敏捷開發(fā)中，應(yīng)該擁抱變化。所以敏捷開發(fā)中推崇重構(gòu)、單元測試、持續(xù)集成等技術(shù)，因為它們可以使變化更容易、更安全。HATOEAS也是這樣一種技術(shù)。想象一下，在項目初始階段，團(tuán)隊對業(yè)務(wù)的理解還不深入，很有可能會得出錯誤的業(yè)務(wù)術(shù)語命名，或者業(yè)務(wù)對象的建模也不完全合適。反映在API上，可能你希望能夠修正API的URI，在非HATOEAS的項目中，由于URI是在客戶端硬編碼的，即使你把它們設(shè)計的非常漂亮(準(zhǔn)確的HTTP動詞，以復(fù)數(shù)命名的資源，禁止使用動詞等等)，也不能幫助你更容易地修改它們，因為你的重構(gòu)需要前端開發(fā)者的配合，而他/她不得不停下手頭的其他工作。
但在采用了HATEOAS的項目中，這很容易，因為客戶端是通過Link來查找API的URI，所以你可以在不破壞API Scheme的情況下修改它的URI。當(dāng)然，你不可能保證所有API的URI都是通過Link來獲取的，你需要安排一些Root Resource，例如 /api/currentLoggedInUser，否則客戶端沒有辦法發(fā)起***次請求。
- 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的入口，客戶端通過他們?yōu)g覽當(dāng)前用戶有哪些資源可以訪問，你可以定義多個Root Resource，并確保它們的URI不會改變
- Link引入的URI可以自由地變化，可能是因為需要重命名資源，也可能是需要抽取出新的服務(wù)(域名變化)
消除重復(fù)的業(yè)務(wù)規(guī)則校驗實現(xiàn)，更容易得適應(yīng)變化
經(jīng)驗告訴我們，不能相信客戶端的請求，所以在服務(wù)端我們需要根據(jù)業(yè)務(wù)規(guī)則校驗當(dāng)前的請求是否合法。這樣確保了業(yè)務(wù)正確，但當(dāng)用戶發(fā)起了請求后才告訴他們請求失敗，有時候是一件令人沮喪的事情。為了用戶體驗，可能會要求某些組件根據(jù)業(yè)務(wù)規(guī)則展示。例如，對于某個業(yè)務(wù)對象，要求編輯按鈕只在當(dāng)前用戶可以編輯的情況下才展示。在傳統(tǒng)的服務(wù)端渲染架構(gòu)下，一般都可以復(fù)用校驗的代碼，而在單頁應(yīng)用中，往往由于技術(shù)棧不同，代碼無法直接共用，業(yè)務(wù)規(guī)則在前后端都分別實現(xiàn)了一次。例如，在我們最近的一次項目中，前后端分別實現(xiàn)了如下規(guī)則：
- 給定一個用戶故事
- 只有它的作者才能編輯它
服務(wù)端通過在用戶故事的API中暴露作者幫助前端完成編輯按鈕的有條件渲染。
- HTTP/1.1 200 OK
- Path: /api/userStories/123
- {
- "author": "john.doe@gmail.com" (1)
- }
1. 與當(dāng)前用戶比較判斷是否渲染編輯按鈕
但如果規(guī)則發(fā)生變化，前后端都需要適應(yīng)這一改變，所以我們用HATEOAS重構(gòu)了一下：
- 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. 現(xiàn)在前端會根據(jù) updateUserStory link是否出現(xiàn)來驗證當(dāng)前用戶是否具有編輯用戶故事的能力
后來業(yè)務(wù)規(guī)則變?yōu)槌俗髡咧猓到y(tǒng)管理員也可以編輯用戶故事，這時候只需要后端去響應(yīng)這個變化就行了。你可能會質(zhì)疑，通過為用戶故事暴露一個 isCurrentLoggedInUserAvailableToUpdate的計算屬性也可以做到。沒錯，HATOEAS并不是唯一的辦法，但作為一種架構(gòu)約束，團(tuán)隊會自然而然地想到它，而計算屬性則要求團(tuán)隊成員有更強(qiáng)的抽象技能。
總結(jié)
HATEOAS提倡在響應(yīng)返回Link來提示對該資源接下來的操作。這種方式解耦了服務(wù)端URI，也可以讓客戶端開發(fā)者更容易地探索API。***，通過Link來判斷業(yè)務(wù)狀態(tài)，還能有效地消除單頁應(yīng)用中的業(yè)務(wù)規(guī)則重復(fù)實現(xiàn)。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
