輕量級Web實戰經驗
介紹完Spring Boot所具備的各項開發輕量級Web的功能特性，接下來，讓我們看看在應用程式中使用這些功能特性時應該遵循哪些最佳實踐。
設計合理的HTTP端點
RESTful風格把位于伺服器端的通路入口看作一種資源，每個資源都使用URI得到一個唯一的位址。從設計規範上講，我們使用名詞來對資源進行描述，标準格式如代碼清單4-77所示。
代碼清單4-77 RESTful風格标準請求格式代碼
http(s)://域名:端口[/版本]/資源1[/子資源2/.../子資源n][/路徑變量]
其中的版本号是可選項，而資源本身則是一種嵌套形式，我們可以在資源内部嵌套各種層級的子資源。一個設計合理的HTTP端點如代碼清單4-78所示。
代碼清單4-78 一個合理的HTTP端點定義代碼
GET http(s)://demo.springboot.com/v1.1/user/friend/10
可以看到上面這個HTTP端點示例的結構非常清晰，我們從這個URL中能夠明确資源的層級以及各級所對應的内容。在傳輸協定上，RESTful風格使用的就是标準的HTTP方法，比如最常見的GET、PUT、POST和DELETE。表4-2展示了RESTful風格的一些具體示例。
表4-2 RESTful風格示例
如果你的RESTful接口寫得足夠标準，其他開發人員應該可以輕松地根據請求方式與URL的語義，猜出這些接口的作用，這也是RESTful風格的核心價值所在。
開發自解釋型Open API
HATEOAS技術的主要亮點是在傳回結果中提供連結，用于指向其他相關對象，使得用戶端開發人員不需要檢視API定義文檔，也知道下一步應該做什麼。在日常開發過程中，如果工作中僅涉及單純的前後端互動接口，實際上并沒有特别的需要來引入HATEOAS。
最适合HATEOAS的應用場景應該是對外開放公共的接口，也就是通常所說的Open API。因為外部團隊的開發人員如果根據Open API的定義就能明确其功能和使用方式，那麼無疑能夠極大降低對接的成本和時間。
使用GraphQL替代RESTful API
在一定程度上，我們可以認為GraphQL是RESTful API的替代物。接下來，我們圍繞這個話題展開讨論。
1. GraphQL的應用場景
需要明确的是，我們并不推薦你在任何場景下都使用GraphQL。對于那些API定義與資源概念比對度較高，也不需要實作類似在使用者資訊内部嵌套家庭成員資訊的複雜查詢場景，傳統的RESTful API仍然是首選，各個HTTP端點之間互相獨立，職責非常明确。但對某些場景而言，GraphQL則更有優勢。
首先，對于業務複雜度較高的場景，推薦使用GraphQL。因為複雜度的産生很大程度上是由于應用程式關聯的系統、子產品以及功能之間的關聯與互動程度很高。這時候如果采用RESTful所提供的基于資源的方式來設計方法，接口定義與資源概念一般很難比對，也就無法很好地表達API的含義。
其次，對于網際網路應用而言，業務和需求變化很快，對應的API定義和資料結構同樣也是多變的。這時候，通過引入GraphQL能夠有效降低溝通成本。
這點對于分布式辦公場景尤其明顯，因為在這種場景下前後端開發人員往往需要反複确認API定義和響應資料類型，溝通成本很高。
最後，如果你的團隊采用的是靈活開發模式，在文檔化管理的流程和工具使用上比較薄弱的話，同樣建議使用GraphQL。GraphQL把開發人員從維護文檔的工作中釋放出來，通過請求和響應結果之間的對應關系，解決前後端資料的一緻性和同步性。
2. 實施GraphQL的政策
關于如何實施GraphQL，我們首先要讨論的是由誰來實作GraphQL，是前端還是服務端呢？這個問題一直被大家争論。對于大多數系統而言，前後端都需要緊密配合，在這個配合過程中，前端開發人員的痛點往往是多于服務端開發人員的。是以，一般場景下前端開發人員對于引入GraphQL的訴求要強
于服務端開發人員。另外，如果采用和RESTful API一樣的開發模式，那麼實作GaphQL的工作量主要是在服務端。服務端開發人員需要基于GraphQL規範重新設計并實作API，通常都建議單獨建構一個資料層來對外暴露GraphQLAPI，如圖4-10所示。
圖4-10 在後端服務中建構資料層示意圖
請注意，GraphQL隻是一種規範，并不是開發語言，而支援GraphQL的開發語言有很多種，包括面向前端的Javascript，面向服務端的Java、Go等。
是以，原則上，前端和服務端都有能力去實作GraphQL。例如，圖4-11所示的就是建構在前端系統和後端服務之間的一個資料層，可以由前端團隊來實作這個資料層。
圖4-11 在前端系統中建構資料層示意圖
在具體實施GraphQL的政策上，我們也可以總結幾條最佳實踐。如果你已經實作了一部分RESTful API，那麼可以讓GraphQL與這部分RESTful API并存發展。尤其是對于那些單一的RESTful服務，可以把GraphQL直接嫁接到已有的RESTful服務上。通過這種政策，RESTful服務中已經實作的業務邏輯層、資料通路層元件都可以得到複用，我們要做的隻是開放一個新的GraphQL通路入口而已。而且，對于一項新技術的引入過程，GraphQL和RESTful服務在一段時間内并存發展也符合其平滑過渡的客觀需求，如圖4-12所示。
圖4-12 RESTful和GraphQL并存發展示意圖
如果你正在采用微服務架構，那麼引入GraphQL的政策就可以在所有後端微服務之前架設一層由GraphQL建構的資料層，并對後端服務提供的資料進行自由組裝之後再開放給前端。這種實施政策類似于微服務架構中的API網關，一方面對前端請求進行适配和路由，另一方面完成前後端之間的解耦。
輕量級Web面試題分析
面試題1：@RestController注解與@Controller注解有什麼差別？
答案：對于使用過Spring Boot的開發人員而言，這是一道送分題。在基于傳統Spring WebMVC開發Web服務時，我們往往需要将@Controller注解和@ResponseBody注解組合在一起使用，目的就是確定傳回的響應結果是JSON格式。而Spring Boot引入的@RestController注解會自動使用JSON實作HTTP請求和響應的序列化和反序列化。
面試題2：在使用RestTemplate工具類時，如果想要同時發起GET和POST請求，你可以選擇使用哪些方法？
答案：RestTemplate工具類提供了一系列非常有用的方法組來實作對HTTP端點的通路，其底層就是基于execute()方法實作的，是以我們可以使用該方法來實作基于各種HTTP方法的遠端調用。但是execute()方法比較偏底層，更多的時候我們使用exchange()這個通用方法，它既能發送GET和POST請求，也能用于其他各種類型的請求。
面試題3：如果讓你開發一款用于HTTP遠端調用的工具，你會如何進行設計并實作？
答案：這是一道開放式的面試題，也是比較有代表性的一類試題，考查你是否能夠在了解目前主流實作工具的基礎上提供一些自身的思考和總結。
對于HTTP遠端調用，建立請求對象、執行遠端調用以及處理響應結果是最基本的流程。而在Spring Boot中，RestTemplate是一個優秀的工具類，基于模闆方法實作了完整的HTTP請求和響應過程。我們也可以把RestTemplate看作HTTP遠端調用工具的一種樣闆，是以，可以參考本章中關于RestTemplate的實作原理給出對該問題的解答思路和過程。
面試題4：REST成熟度模型是什麼樣的？你能簡要描述什麼是HATEOAS嗎？
答案：很多時候，我們習慣使用傳統的RESTful API來實作HTTP端點，但實際上這并不是REST的全部。隻有使用了超媒體的Web API才代表REST模型的最高成熟度。關于如何實作這種成熟度，業界也提供了HATEOAS，也就是使用了超媒體的應用狀态引擎。針對這類面試題，重點是講清楚多媒體、超連結、超媒體等這些核心概念，一般不需要對細節做過多講述。
面試題5：你能簡要描述Spring HATEOAS的開發模式和應用場景嗎？
答案：Spring HATEOAS是Spring家族中專門針對HATEOAS的開發架構，它的開發模式實際上和RESTful API在本質上是一緻的，都是圍繞“資源”這一核心概念設計的開發流程。與實作普通Controller不同，Spring HATEOAS對資源和連結的實作有特定的一套API，并且提供了強大的資源裝配器來完成對資源的組合。Spring HATEOAS的應用場景也比較廣泛，在Spring Boot内部就大量使用HATEOAS來暴露HTTP端點，典型的例子就是Spring Boot Actuator元件。而對于日常開發而言，推薦使用Spring HATEOAS來暴露面向外部系統的Open API。
面試題6：結合日常開發過程，你有沒有在使用RESTful API時碰到一些痛點？
答案：這也是一道典型的開放式面試題。這種問題不一定有标準的答案，主要考查的是你對開發過程的思考和總結。事實上，關于前背景API聯調和對接過程中所碰到的問題，每個公司、每個團隊都存在，關鍵在于我們如何看待和定位這些問題。在本章中提到的遠端調用的資料格式、參數和傳回值、多次請求以及HTTP端點數量的問題在日常開發過程中都很典型，我們可以結合自身的一些案例進行讨論，充分表述自己的觀點。
面試題7：使用過GraphQL嗎？你覺得它有什麼優勢？
答案：這道題的問法雖然和上一題完全不同，但回答的方式實際上是類似的。在大多數團隊中，GraphQL目前還沒有得到應用。是以，這道題更多考查的是你的知識點的廣度。如果你了解這個主題，那麼可以按照本章中對這一主題的講述思路組織内容，并用自己的語言進行表述。如果你不了解這個主題，那也需要做到能夠變通，通過提出一些問題把GraphQL的含義搞清楚，然後按照上一題的思路進行表述。
本文給大家講解的内容是springweb服務建構輕量級Web技術體系：輕量級Web實戰經驗
- 下文給大家講解的是springweb服務應用響應式Web開發元件：響應式程式設計和Spring Boot