Web開發領域的REST運動已經進行了很多年了，在REST的Richardson成熟度模型提出后，第3級——HATEOAS的應用——仍然沒有得到廣泛應用。事實上，其中一個難點在于客戶端如何支持HATEOAS。之前很多REST相關書籍聚焦于如何打造服務端的RESTful API，本書則著重研究RESTful客戶端，介紹了如何把一個針對服務端規約硬編碼的定制客戶端重構為一個支持HATEOAS的通用客戶端，并提供了多格式支持、超媒體類型、版本化、微服務等相關問題的全面指導。本書附有所有樣例代碼的GitHub地址，方便讀者快速理解和實踐。本書適合Web應用開發者，尤其適合希望Web應用程序的服務端與客戶端能夠獨立演化的Web架構師。

推薦序：一場與超媒體的未了情緣
在2007 年，當我初次翻譯Roy Fielding 關于REST 的博士論文（中文名為《架構風格與基于網絡應用軟件的架構設計》）時，自己對Web 的整體架構是毫無概念的。無知者無畏，當時我僅僅是出于求知欲就開始了翻譯工作。后來我發現這個挑戰嚴重超出了我的能力范圍，Fielding 的博士論文是我翻譯過的專業技術著作中難度最高的。后來我在2013 年重新翻譯了這篇博士論文，力求把初次翻譯時的大量問題和留下的遺憾都彌補上，而不至于誤人子弟。
這篇博士論文是一座內涵豐富的寶藏，可以說是2000 年前Web 架構相關論文中的集大成者，其重要性不亞于Tim Berners-Lee 爵士的論文。文中系統地闡述了HTTP 1.1 協議背后的設計原理——REST。絕大多數不理解REST 思想的Web 開發者都會陷入兩個誤區之中：一個是將HTTP 簡單看作是一種傳輸協議（而不是應用協議），另一個是完全忽視超媒體的重要性。在2005 年REST 思想隨著Web 2.0 的興起和迅速發展而逐漸普及之后，脫離第一個誤區的Web 開發者越來越多，但是能脫離第二個誤區的Web 開發者還是極少數。Fielding 博士其實從最初就認為REST 和超媒體是不可分割的，而HTTP 1.1 最重要的設計目標就是更好地支持超媒體。在當時的語境中，這個超媒體自然就是HTML。因為關于超媒體的誤解如此之多，所以Fielding 博士在2008 年寫了一篇博客文章RESTAPIs Must be Hypertext-driven（《REST API 必須是超文本驅動的》）。
這篇博客引起了Web 開發社區的廣泛討論和反思，隨后RESTful Web Services 一書的作者Leonard Richardson 提出了一個Richardson 成熟度模型。這個模型將RESTful API 劃分成了3 個等級，把能夠熟練應用超媒體的RESTful API 列為了最高等級——第3 級。然而很多年過去了，在普通Web 開發者看來，這似乎仍然是一個烏托邦式的目標。有些RPC 鐵桿粉絲總是會拿這個來譏諷REST 愛好者，把他們說成是中看不中用的API 設計美學愛好者。這些傳統的觀點過于強大，以至于REST 愛好者對于在API 設計中使用超媒體也視為畏途。
當然，我們都是工程派，而不是學院派，隨便給別人亂扣學院派的大帽子是一種不尊重人的行為，也是不求甚解的體現。包括REST 思想的創造者Roy Fielding 也是“如假包換”的工程派。他早年為很多開源項目貢獻過大量代碼，還指導了大量HTTP 客戶端/ 服務器端開發團隊，他的實戰能力肯定在絕大多數開發者之上。REST 當然并不是一種API設計美學，它更像是中庸之道，包含了設計Web 應用的各種架構權衡。雖然Fielding 在設計HTTP 1.1 和撰寫博士論文時，超媒體主要指的是HTML，但是REST 是通用的理論，能支持的超媒體類別遠不止HTML 一種。在Fielding 發表2008 年博客文章之后，Web開發社區與超媒體相關的研究和開發實戰非常活躍，出現了大量新型的超媒體，而且越
新出現的超媒體，越是基于JSON 而非XML 的。一直很支持REST 設計開發的O’Reilly出版社，也不失時機地出版了很多REST 開發相關的圖書，這些圖書目前已經形成了一個強大的系列，包括：
y RESTful Web Services
y RESTful Web Services Cookboo（k 中文版為《RESTful Web Services Cookbook中文版》）
y REST in Practice（中文版為《REST 實戰》）
y RESTful Web APIs（中文版為《RESTful Web APIs 中文版》）
y RESTful Web Clients（中文版為《RESTful Web Clients：基于超媒體的可復用客戶端 》，即
本書）
另外還有很多針對某個開發平臺的REST 開發圖書，例如：
y RESTful .NET
y Building Hypermedia APIs with HTML5 and Node（中文版為《使用 HTML5 和 Node
構建超媒體API》）
y PHP Web Services: APIs for the Modern Web
在這些優秀的REST 開發圖書之中，涉及了超媒體的圖書中最有代表性的是如下3 本：
y REST in Practice（中文版為《REST 實戰》）
y RESTful Web APIs（中文版為《RESTful Web APIs 中文版》）
y RESTful Web Clients（中文版為《RESTful Web Clients：基于超媒體的可復用客戶端 》，
即本書）
我有幸作為REST in Practice 一書的翻譯負責人，趙震一負責翻譯RESTful Web APIs，曾著負責翻譯RESTful Web Clients。我們就像是一個接力賽的團隊一樣，在7 年的時間里，把接力棒傳遞下去，希望能通過這3 本書向國內的Web 開發者全面展示RESTful API 和超媒體的獨特魅力。
這3 本書由淺入深，逐步揭開了支持超媒體的第3 級RESTful API（也就是所謂的Web API）的神秘面紗。尤其是第3 本書RESTful Web Clients，令人信服地展示了使用超媒體之后，對于API 客戶端代碼的復用性和松耦合起到的巨大作用。除此之外，這本書最重要的貢獻是讓超媒體變得如此平易近人，要達到這個目標其實是非常困難的。作者Mike Amundsen 雖然功力深厚，但為了保證本書的質量，原著足足推遲了一年時間才上市。結果不負眾望，Mike 為讀者奉獻了一本高質量的圖書。連Roy Fielding 在Twitter 上也承認Mike Amundsen 對于超媒體如何使用的理解，與REST 博士論文是最接近的。相信認真閱讀完本書的Web 開發者對在API 設計中適當使用超媒體不再會那么猶豫。其實在API 設計中適當使用超媒體，就應該像我們平時寫代碼時要寫單元測試一樣習以為常，并且熟能生巧，不斷探索在API 設計中使用超媒體的樂趣。
另外我還建議讀者在讀完RESTful Web Clients 之后，再去認真讀一下Mike Amundsen 的上一本書RESTful Web APIs，因為這兩本書有很強的關聯性。RESTful Web APIs 雖然很棒，但是偏重于概念闡述，實戰性不足，RESTful Web Clients 彌補了RESTful Web APIs 在實戰性方面的缺憾。思想的發展是有傳承性的，沒有幾年前的RESTful Web APIs 就不會有RESTful Web Clients。對于API 來說，服務器端是皮，客戶端是毛，皮之不存，毛將焉附？
順便說一下，雖然現在HTTP 1.1 已經升級到了HTTP 2，不過REST 和超媒體的思想是完全適用的。如果熟悉HTTP 2，你會發現，其實HTTP 2 的設計還是為了更好地支持超媒體（特別是HTML5），HTTP 2 仍然是與超媒體緊密相關的。這再次證實了Fielding在REST 博士論文中所闡述的思想，REST 是Web 自身的架構風格，REST 就是一切優秀Web 應用的靈魂，而REST 自身的靈魂就是超媒體。超媒體是計算機軟件領域最偉大的思想之一，它是Web 應用取之不竭的力量源泉。
開卷有益，最后我代表國內的Web 開發者感謝本書的兩位譯者曾著、徐必濤的辛勤工作。
也感謝博文視點張春雨老師，他10 年來堅持不懈地支持REST 開發圖書的出版。

Web 架構師　李錕
2018 年3 月4 日于上海
譯者序
2017 年年末，就職小米的一位前同事送了我一枚F 碼，我用它搶購到一枚小愛音箱。我滿懷期待地裝上“小愛同學”，希望能夠通過她用語音控制所有小米產品。但我失望地發現，早先我購買的YeeLight 床頭燈并不能接受“小愛同學”的指揮——YeeLight 床頭燈的客戶端只能適配其出廠時的服務端所提供的功能，在服務端擴展新的功能，比如接入智能語音控制之后，已經發布的客戶端卻無法跟上，無法獲得新功能。
隨著互聯網尤其是物聯網的發展，跨企業、跨行業的互聯需求越來越多，上述遺憾會頻繁發生，無疑會造成巨大的浪費，也阻礙了物聯網的發展。我們迫切需要服務端和客戶端相互獨立演化的能力，這正是RESTful 服務端與客戶端的用武之地，也是本書的主要目的。
本質上，服務端和客戶端獨立演化的能力取決于雙方的實現細節的解耦程度。首先，如果服務端與客戶端緊密耦合，服務端變更就很可能造成客戶端失效。例如，服務端和客戶端通過RPC 的IDL 來約定服務接口，那么當服務端的變更引起過程名、參數或返回值的變更時，客戶端就很難不受其影響。又例如，服務端的Web Service 遵循一套URL template 規約，客戶端根據服務端提供的規約文檔編碼，如果服務端改變了資源名稱或資源之間的關聯關系，也會導致客戶端失效。其次，與服務端緊密耦合的客戶端顯然也無法正常接納服務端推出的新功能。
REST 解決的思路就是將可能變化的部分抽象出來，融入服務端響應的消息體中，如果客戶端擁有解讀這些變化的能力，也就使雙方都獲得了獨立演化的能力。
在過去我們非常熟悉的“通用瀏覽器+ 服務端渲染邏輯（CGI、JSP、ASP、PHP 等）+HTML”方案中，服務端輸出了整個HTML 文檔，自然也包含了服務端所有可能變化的部分。從理論上說，客戶端和服務端的確獲得了相互獨立演化的能力——瀏覽器是通用的，不需要應用程序員編寫任何客戶端代碼，也并不因為服務端改變了JSP 腳本或增加一個功能，就需要升級瀏覽器。這是一個極為流行的方案，成功地擠掉了C/S 結構的份額，成為當時互聯網應用的主流方案。
然而，這個服務器渲染的方案并不夠好。因為服務端響應是完整的HTML 文檔，不僅有業務數據而且包括渲染的每一個細節，客戶端要么全要，要么全不要。如果客戶端希望對業務數據再加工，或者局部渲染，就不得不剝離易變的其他元素，例如＜p/＞ 這個渲染相關的元素。寫過爬蟲的程序員應該深有體會，好不容易把有用數據從HTML 大雜燴里提取出來，結果目標網站稍微改動一些風格布局，原先的爬蟲程序就失效了。由于難以局部渲染，人們不得不忍受HTML 頁面跳轉的糟糕體驗。AJAX 和JS 客戶端渲染腳本的興起成為壓倒駱駝的最后一根稻草，傳統的服務器渲染方案被逐步取代了。

擁有JS 渲染腳本和靜態HTML 模板的富客戶端，將服務端渲染方案中view 的職責從服務端搶了過來，服務端只輸出數據，不必帶上各種HTML 標簽。職責的分離大大促進了復用，一個服務端可以擁有多個不同展現形式的客戶端，一個客戶端可以mashup多個服務端，跨企業的應用互聯變得很流行。但這樣一來，過去C/S 結構的老問題——服務端與客戶端緊耦合的毛病又出現了，如果客戶端團隊與服務端團隊不是同一撥人，獨立演化造成不兼容就會成為大問題。

客戶端渲染和客戶端服務端獨立演化能否兼得？本書給出了答案。

本書首先講到，如果服務端響應中包含下一步操作的所有可能路徑，客戶端應該能夠正確理解和處理這些路徑代表的操作，人作為交互模型的主動角色，通過操控客戶端選擇路徑，形成“探索地圖”式的人機交互形式。其中客戶端是不需要事先知道服務端提供的操作路徑的，這就形成了服務端和客戶端對于操作路徑的獨立演化的能力，換言之，服務端可以修改、增加、刪除這些操作路徑而不會引起客戶端失效。
然后，作者將類似“操作路徑”這樣的客戶端需要識別的變化部分歸納并抽象為OBJECT、ADDRESS、ACTION（簡稱OAA）三個重要元素，客戶端需要理解響應中攜帶的OAA 的元數據，才能有效處理OAA 元素的變化。這些元數據如下。
y OBJECT 元數據 ：服務端返回業務數據的元數據，例如對象中字段的類型、長度甚至語義等，這些元數據能夠幫助客戶端正確地渲染展現數據。
y ADDRESS 元數據：響應中業務數據的關聯操作列表，包括名字、URL、展示名稱等，能夠指示客戶端展現當前可操作的最新功能。
y ACTION 元數據：對 ADDRESS 列表每一項操作的詳細描述，包括參數的元數據（與OBJECT 字段元數據類似）、名字、URL、HTTP 方法、展示名稱等，能夠指示客戶端引導用戶正確地發起這個操作。

接著，作者在第3 章講述了如何在服務器響應中包含OAA 這些可變因素，在第4 章、第6 章、第8 章講述了如何通過一些表述格式讓客戶端理解和正確處理OAA。難得的是，作者并沒有假設理想化從頭開始的場景，而是讓虛擬主人公Bob 和Carol 從老團隊和傳統的設計中，將傳統的個性化定制客戶端一步一步重構和擴展為可復用的支持多種表述格式的通用客戶端。
最后，作者還講述了處理版本化和微服務需要注意的地方。RESTful Web 客戶端是整個REST 風格應用（服務端和客戶端）的一部分，服務端已經有不少著作，《RESTful Web Clients ：基于超媒體的可復用客戶端》則是HATEOAS 的RESTful 應用缺失的最后一塊拼圖，對于實踐RESTful 服務和客戶端有重要的指導意義。
作為譯者，特別提醒讀者在閱讀過程中留意幾點，第一，本書是如何將系統中穩定不變的部分、較穩定不易變的部分和經常變化的部分相互分離，分別在服務端、客戶端、通信報文中描述，以期獲得最大復用的同時促進服務端和客戶端的獨立演化的。第二，從服務端渲染方案的缺陷我們可以得出結論，客戶端并不是越通用越好。當縮小復用范圍、聚焦某個行業領域時，保留客戶端與服務端之間對該行業領域語義的耦合和隱式的規約，反而能夠增強在領域內的復用程度而不影響行業領域內的復用。展望未來，RESTful 運動可能會產生若干包含協議語義的通用格式與具體應用領域DSL 相結合的應用模式。最后，本書留了一個待解決的問題，即當客戶端不是由人類，而是由另一程序操控時，地
圖將退化為規則操控的路徑，成為自動化的客戶端；當這個規則是AI 操控時，這個客戶端將進化為智能客戶端，這時，YeeLight 將不僅能接受“小愛同學”的指揮，而且能勝任更多預先并不知道的工作。
在翻譯的過程中，我得到了李錕、趙震一等翻譯REST 系列服務端著作的前輩的幫助，和REST 實戰討論組里的李念輝等學友的討論也讓我受益匪淺。另外，出版社的張春雨老師對譯文的規范性提出了不少意見和建議，在此一并表示感謝。由于水平有限，錯漏難免。如讀者發現錯漏，請不吝賜教。
原書推薦序
在本書的先驅之作RESTful Web APIs 的前言中，Sam Ruby 說道：
希望RESTful Web APIs 這顆鵝卵石可以像它的先驅RESTful Web Services 那樣具有影響力。但誰也說不好，也許七年之后這一切又將重演，從而強調表述性狀態遷移（Representational State Transfer）仍然沒有受到應有重視的方面。

現在雖不是此前的七年之約，但RESTful Web Clients 已經如期而至。Mike 在API 領域精耕細作多年，通過本書的文字，我們可以領略他在寫作和思想上一貫清晰的風格，以及那部分被忽略的Web API。

REST 一詞出自Roy Fielding 的博士論文《架構風格與基于網絡應用軟件的架構設計》。在論文的前面部分，Fielding 介紹了用于描述REST 的七個基本架構約束，第一個是客戶- 服務器（Client-Server，CS），其中描述如下：
分離關注點是在客戶端- 服務器約束背后的原則。功能的適當分離會簡化服務器組件，從而提高可伸縮性。這種簡化所采用的形式通常是將所有的用戶界面功能（user interface functionality）移到客戶組件中。只要通信的接口不發生改變，這種分離允許兩種類型的組件獨立地進化。

顯然，通過這種方式設計系統時，服務端和客戶端同等重要。然而，那些基于Fielding論文所完成的工作中普遍存在一種偏見：幾乎所有的工作都聚焦在服務端，卻很少討論客戶端。這樣便遺漏了一個非常重要的部分，RESTful 架構的一些好處只能通過良好設計的客戶端來實現了。雖然有許多客戶端- 服務器架構風格的系統，但都沒有遵循Web中的一些原則。如果我們必須采取某種方式讓服務端更接近Web 的運行方式，那么我們也必須改變客戶端的編寫方式。

事實上，在我們構建Web API 時，這是向Web 思維方式轉變的一個難點所在。對此，我與熱衷于部署超媒體技術的組織有過諸多討論，他們不懈地將這些努力付諸實踐。我相信這其中的很多困難都來自超媒體的生產，因為并沒有考慮到API 消費方式的變化。如果當API 設計人員期望構建一個Web API 客戶端時，可以采用消費其他API 的原則來消費RESTful API，那么結果將會令人沮喪。不過，這一切都是可以理解的，畢竟那些倡導這種架構風格的人員幾乎都集中在API 的生產方。

事后來看，這種缺陷其實很明顯：如果我們只關注方程的一邊，我們該如何設計一個好的系統呢？我確信這種情況是現如今人們對API 認識所導致的一個二次效應：我的組織關注的是如何為我的產品提供一個API，但使用這個API 的是你的組織，所以如何處理它是你分內的事。過去的五到十年中，這種關于API 的潛在情緒有所擴大：轉向“簡單的API，我們不需要復雜的SDK 來完成工作”。同時，提供API 客戶端的組織也常常被投以懷疑的目光。不過，我們現在可以看到事情已經開始反轉，開發人員已經厭倦每次為新的API 重新部署一次客戶端。官方提供的SDK 正被逐漸正視，通過這些SDK，
API 的消費者可以更多地將關注點放在自己的應用上，而不是API 的集成上。
此外，Web 也越來越被看作是應用平臺，而不是用于分享文本文檔的一種簡單方式。隨著專屬平臺的興起，特別是在移動領域，那些熱愛Web 自由和開放的人們，正在動員更多的人來顯著擴展Web 平臺的能力。為了利用這一優勢，隨著他們的產品愈發雄心勃勃，應用也隨之萌芽了越來越多的JavaScript 代碼。而這些應用正是另外一種客戶端，隨著時間的推移，它們也將日趨重要。

隨著格局的轉變，組織需要再次考慮方程兩邊的平衡問題。從廣義上講，我認為這會產生更好的API，但它們不會都是“玫瑰”。正如我之前所提到的，你可以買到無數的書籍來幫助你了解方程的服務端一邊，但是在客戶端方面卻完全沒有一個類似的指導手冊——至今仍是如此。
自從Mike 告訴我他開始著手這一工作以來，我一直在期待著這本書，而他也確實沒有
讓我失望。對于Web API 方程式中缺失的那部分，本書堪稱一部夢幻般的指南，我相信
它的作用和影響在未來數年內將得到關注。希望你也可以像我一樣享受這本書的閱讀過
程。
——Steve Klabnik

前言
“始階段是工作中最重要的部分。”
——柏拉圖（Plato）

基于Web 的REST 和超媒體服務正日趨普遍，但卻鮮有客戶端可以利用這些API 的強大功能。這主要是因為缺乏創建成功的超媒體客戶端的技術和模式——長期以來它們一直被忽視。然而，如果可以采取恰當的方式，基于超媒體的客戶端應用將會比典型的一次性客戶端具有更強的穩定性和靈活性。

本書旨在為讀者提供一個堅實的背景知識和一些可工作的示例源碼，這些示例為如何處理超媒體API 提供了明確的建議。本書的主要思想之一是客戶端應用程序應該依賴于Request、Parse 和Wait 所構成的循環，我簡稱其為RPW 循環。這是所有電腦游戲采用的實現方式，也是所有事件驅動接口從窗口式工作站（windowing-style workstation）到響應式機器接口（reactive machine interface）的工作方式。

有人告訴我，一些前端的開發人員可能會認為RPW 模式比較生僻，甚至也有人認為我的建議比較“激進”。對于這些觀點，我都能理解。當下，眾多的前端開發庫和實踐都在致力于設計用于專門構建的一次性用戶界面，這些界面難以修改，并且很難在運行時對服務提供的新信息做出反應。不過，在閱讀本書的例子后，我希望前端開發人員（他們中的大多數都比我的經驗更豐富）能夠在目前初步工作的基礎上創造出更豐富的最佳實踐、工具和可重用的庫，為越來越多的超媒體API 打造高質量的用戶體驗，力爭在不需要頻繁升級的情況下滿足高質量的用戶體驗需求，以及不斷發展的服務接口自適應客戶端的需求。
本書講了什么
本書將帶領讀者開啟一段從個性化定制實現到強大的通用客戶端應用的旅程，同時向你展示如何利用那些支撐萬維網良好運行的基本原則。本書包括以代碼為中心的章節信息和對相關重要主題的探索，比如表述器模式、人機交互模型和Web API 在版本控制上的挑戰等。當然，其中也少不了大量的代碼（我為本書創建了20 多個GitHub 倉庫），包括一些小的代碼片段。不過，這些片段單獨看可能不易理解。因此，我會為讀者指出完整的在線代碼庫的位置，你可以在相關代碼庫中找到本書所涵蓋的全部功能實例。
各章內容
本書探討了通用超媒體風格客戶端的世界，包括它們的外觀、與典型JSON 對象客戶端的區別，以及客戶端和服務端開發者如何構建更易于支持和適應的系統。本書包含了一些專項討論所選格式（如HTML、純JSON、HAL、Siren 和Collection+JSON）的章節，以及所有Web 開發人員需要熟悉的理論和實踐的章節，包括服務端對消息格式的支持、人機交互模型、版本控制，以及一個在同時與多個獨立的后端服務進行交互時可以支持多種超媒體格式的解決方案。
本書的大多數章節都可以獨立成章，在閱讀時可以不講究先后順序。不過，為了更充分地理解和吸收本書的內容，我鼓勵你將本書看成一次單程旅行，按照順序從頭讀到尾。這里簡單介紹一下本次旅程的路徑。
第1 章，從HTML 到簡單Web API
本章向我們介紹了一個經典的純HTML 客戶端。我們將通過它來了解瀏覽器的基本工作原理，以及它們是如何影響人們看待Web 中那些超媒體格式的。此外，本章還介紹了將純HTML 服務轉換為一個原始的純JSON 服務的過程。該服務將是我們為本書構建的所有其他客戶端應用程序的基礎。
第2 章，JSON 客戶端
大多數的客戶端Web 開發人員都會構建JSON 客戶端，它會記住所有的URL，處理靜態對象，并通過固定的工作路徑來導航。構建JSON 客戶端是一個很好的開始，不過時間卻證明它是一個糟糕的工作方式。在本章中，我們將討論如何克服在維護純JSON 風格客戶端應用程序時的挑戰。
第3 章，表述器模式
表述器模式是處理服務器輸出的一種簡單而重要的方式，也是將內部對象模型轉換為外部消息模型的過程。我們將在本章中審視該模式（及其源頭），并介紹如何使用服務器上的Web 服務遷移語言（WeSTL）和瀏覽器客戶端上的HTML DOM 將該模式應用于API 提供方。
第4 章，HAL 客戶端
HAL 媒體類型是目前較為流行的超媒體格式之一。比如在Amazon 的Web 服務團隊中，至少有兩個API 使用了HAL。對于所有Web 客戶端都需要處理的三個重要元素，HAL 負責處理其中之一： ADDRESS 挑戰。我們將看到如何將HAL 作為消息格式來構建一個通用客戶端，以及如何通過HAL-FORMS 擴展來提高HAL 的處理能力。
第5 章，可重用客戶端應用的挑戰
你會注意到，我們所構建的多數客戶端看起來都很類似。從本質上講，我們正在建立能夠在探索周圍世界（以某種有限的方式）的過程中發展自己的“探險者”。這些客戶端都采用了Request—Parse—Wait 循環，即RPW 模式。該模式基于我們如何與世界交互這一命題下的幾個經典概念，我們將在本章中探討它們。
第6 章，Siren 客戶端
Siren 內容類型是另一種強大的超媒體類型。Siren 目前被用作Zetta IoT 平臺的一部分，旨在處理Web 客戶端的三個關鍵任務中的兩個：ADDRESS 和ACTION。我們將看到使用Siren 作為消息格式來構建一個通用客戶端，也會通過探索Siren 拓展（Profile for Object Display，即POD）來增強它在UI 上顯示元數據的能力。
第7 章，版本化與Web
當你開始將超媒體類型作為客戶端Web 應用程序的基礎時，API 版本的概念會發生什么變化？本章將討論管理隨時間變化的各種嘗試，以及如何依賴基于消息的超媒體風格的API 來減少當接口特性發生變更時也要變更接口契約的問題。
第8 章，Collection+JSON 客戶端
在本章中我們將探討另外一種超媒體格式：Collection+JSON，或稱為Cj。Cj 能夠處理Web 客戶端中的所有元素：OBJECT、ADDRESS 和ACTION。我們將看到如何將Collection+JSON 作為消息格式來構建一個通用客戶端，并學習如何擴展Cj 的數據顯示和驗證程序。
第9 章，超媒體與微服務
創建一個可以無縫調用多個服務的通用超媒體客戶端需要什么？如果這些服務使用的超媒體類型各不相同，又需要什么呢？當我們談論消息格式時，該怎樣制作一個可以“說”多種語言的客戶端應用？這一切將在最后一章中揭曉。
對話
本書的所有章節都以簡短的小插曲或對話開始和結束。我們通過這些虛構的對話來說明，組織在思考如何在互聯網上創建可擴展且穩定的項目時所遇到的挑戰。這些對話既是各章主題的鋪墊，也是主題的總結。
此外，對話也是一種提示，讓讀者有機會思考所提出的挑戰，以及如何應對這些挑戰并給出解決方案。每章從對話開始讀起，讀完后花幾分鐘時間來描繪（也可以寫下來）一下你對于如何解決問題的想法。這種方式可以幫助你對書中提供的解決方案形成更深刻的認識，并對自己的問題解決能力有額外的洞察。
最后，這些對話還可以幫助那些只想跳躍閱讀書中部分內容的讀者收獲一些感悟。你可以單獨閱讀對話，并收集相關的基礎信息。各章內容也正是對對話中的細節和微妙之處進行了深入討論。你可能會發現，至少在某些章節中，閱讀對話可以獲取當前主題或挑戰相關的所有信息，而且還很不錯。
藝術作品
本書包含了一些才華橫溢之輩的藝術作品和圖表。Dana Amundsen， 路易斯維爾（Louisville） KY 的一位成功的藝術家，和我一起創作了本書中出現的人物Bob 和Carol。此外，她還設計了示例程序中所使用的BigCo 徽標。事實上，Dana 創作的作品比本書所包含的要多得多，希望在不久的將來可以通過其他方式將這些藝術作品分享出去。

本書中的圖表均由我的好友Diogo Lucas 創作，他是一位資深的軟件工程師、架構師、演說家和老師。我第一次遇見Diogo 是在前往巴西（他的居住地）的旅途中，當談論關于本書的一些想法時，他向我展示了令人驚嘆的草圖。我抓住這個機會邀請他創作插圖，很幸運，Diogo 欣然同意貢獻他的藝術才華。
本書所使用的Dana 和Diogo 的藝術作品，均是根據Creative Commons - Attribution-NoDerivatives 4.0 International(CC BY-ND 4.0) 獲得授權的。Dana 和Diogo 為本書增加了很特別的內容，我非常感謝他們。
本書沒有講什么
本書在相對有限的篇幅中涵蓋了較廣的內容范圍。為了做到這一點，我需要刪減一些有用的素材。接下來簡單介紹一下那些沒有涵蓋在本書中的內容。
用戶界面設計
雖然我在本書中提到了關于用戶界面設計的一些資料，但它們都是比較粗略的。而且通常情況下，我不會花費時間來了解人機交互（HCI）或設計方法的細節。
我也要提醒一下讀者，本書示例中所提供的都是基本的UI。我主要的關注點是網絡和消息層面的技術，即允許服務向客戶端應用程序提供可識別和有用的超媒體提示。在客戶端解析和激活這些超媒體信息的最佳實踐方面，我也付出了時間。而關于界面修飾和視覺吸引力改進方面的工作則不是本書的重點（如需了解，請關注這方面的專業人士）。
特別感謝Benjamin Young
我要特別感謝我的老朋友、資深的Web 開發人士Benjamin Young。他一遍又一遍地檢查了我的基本UI 設計，并為所有的客戶端應用程序提供了一致的外觀。說實話，我給Benjamin 的創作空間是有限的，但他仍然針對所有應用設計了穩重而一致的風格指南。如果它們看起來都很賞心悅目，那正反映了Benjamin 的才華和堅持；如果
它們在某些方面不符合標準，那是因為我并沒有給Benjamin 所需要的自由。
超媒體基礎
這本書不會花費太多篇幅來討論將超媒體作為實現風格時的價值收益，也不會深入講解如何在你自己的項目中使用超媒體創建一個具體的例子。關于超媒體Web API 的歷史和價值基礎，我此前的作品RESTful Web APIs（和Leonard Richardson 合著，中文版為《RESTful Web API 中文版》）以及Building Hypermedia APIs with HTML5 and Node（中文版為《使用HTML5 和Node 構建超媒體API》）都是更好的參考資料。所以，關于這方面的信息，我建議讀者閱讀這兩本書或其他資料。
用HTML、CSS 和JavaScript 編程
最后，本書也沒有涉及Web 的編程基礎，例如HTTP 協議、HTML5、JavaScript 和CSS等方面。這些都是非常重要的主題，但是這遠遠超出了這本小書要討論的范圍。這些主題有很多相關的書籍，我相信讀者可以方便地找到。
源代碼
這本書涉及相當多的源代碼。幾乎每章都有一個工程項目，有的甚至有兩個或更多個。如果將這些源碼都放在書里，那將導致閱讀和瀏覽很不方便。因此，本書中出現的都是一些非常重要而簡短的代碼片段。
完整的源代碼可以在GitHub 的公有倉庫中獲得。這些資料將會不定期地更新，所以它是本書中所有源代碼片段的最準確的來源。建議讀者clone或fork 這些源代碼，對于必要的變更，也歡迎提交pull request。
外部參考
在整本書中，我引用了很多外部資料和參考文獻，包括其他書籍、發表的論文、文章、公共標準和博文。我會在書中提到相關的參考資料，但不是以直接引用或者腳注的形式，因為這會影響閱讀的流暢性。我會在每個章的末尾增加一個部分，列出參考資料的名稱和相關的鏈接。
本書所使用的約定
以下是本書所使用的排版約定。
中文楷體或英文斜體（Italic）
表示新的術語、URL、郵件地址、文件名稱和文件拓展名。
等寬字體（Constant width）
表示程序片段，也可以用在正文中表示變量名或函數名等程序元素、數據類型、環
境變量、語句和關鍵詞等。
等寬字體加粗（Constant width bold）
表示應該由用戶輸入的命令或其他文本。
等寬字體加斜（Constant width italic）
表示應當被用戶自定義的值或上下文決定的值所替換的文本。
這個圖標表示提示或建議。
這個圖標表示一般的說明。
這個圖標表示警告或注意。
O’Reilly Safari
Safari（以前的Safari Books Online）是企業、政府、教育者和個人的會員制培訓及參考平臺。訂閱者可以從一個完全可搜索的數據庫中獲得來自250 多家出版商提供的成千上萬的書籍、培訓視頻、互動教程，這些出版商包括O’Reilly Media、Harvard Business Review、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley＆Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones＆Bartlett 和Course Technology。若想獲得更多資訊，請訪問http://oreilly.com/safari。
聯系我們
請將對本書的評價和發現的問題通過如下地址通知出版社。
美國：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中國：
北京市西城區西直門南大街2 號成銘大廈C 座807 室（100035）
奧萊利技術咨詢（北京）有限公司
我們提供了本書網頁，上面列出了勘誤表、示例和其他信息。
致謝
這本書的出版離不開很多人的傾情奉獻和幫助。我特別感謝那些自愿閱讀和評論本書早期草稿的讀者，尤其是Todd Brackley、Carles Jove i Buxeda、Pedro Felix、Mark Foster、Toru Kawamura、Mike Kelly、Steve Klablnik、Ronnie Mitra、Erik Mogensen、Irakli Nadareishvili、Leonard Richardson、Kevin Swiber、Stefan Tilkov、Ruben Verborgh 和Jeremy Wilken，他們在本書的創作過程中提供了寶貴的反饋和建議。

我還要感謝O’Reilly 團隊的所有支持和信任，特別是Simon Foley 和Simon St.Laurent在漫長的創作過程中給我的源源不斷的鼓勵。此外，感謝我的出版編輯Colleen Lobner，在她將我的文字整理出版的過程中，不得不忍受我無盡的細微布局和字體問題。我也特別感謝API 學院和CA Technologies 的同事在整個項目中所提供的幫助和支持。最后，我要再一次感謝我的家人。當我著手處理問題、戴上耳機進行長時間思考，以及當我陷入細節和測試場景的沉思時，你們用耐心和幽默包容著我。謝謝你們。
讀者服務