引言
開局兩張圖，內容全靠編～
區別分離和半分離的標志在於Controller層由不由前端控制，Controller在前端手里，前端手里握着組裝數據的邏輯，那就是前后端分離！否則就是半分離！
那么，半分離和分離的架構是長下面這樣的
ps:中小型公司慎重，不要玩前后端分離架構！前端工作量賊大！
那么用上了前后端分離架構后，后端的API一般會按照Restful風格來設計！ResultFul推薦每個URL能操作具體的資源,而且能准確描述服務器對資源的處理動作，通常服務器對資源支持get/post/put/delete/等，用來實現資源的增刪改查。前后端分離的架構下，這些api-url是對接的橋梁，采用ResultFul接口地址含義才更清晰、見名知意。
那么，在實踐RestFul風格的API的有一個致命的缺陷，是神馬類？嗯，帶着你的疑惑開始本文
正文
RestFul的缺陷
假設，此時我們有兩個資源分別是Book和Author，這兩個資源對應的ER圖如下
相應的API有
POST /books
GET /books/{id}
POST /authors
GET /authors/{id}
我們有一個需求，需要查詢id=1的圖書信息！
那我們的請求地址是這樣的
GET /books/1
返回結果是這樣的
[{
"id": 1,
"bookname": Harry Potter,
"price": 56.00,
"author_id": 2
}]
這時候前端MM拿到這個結果后，傻了眼！這里怎么能直接返回author_id呢，難道直接把author_id顯示在界面上么？不可能啊，界面上要顯示的是author_name才行！
OK，那么在這種情況下，有兩種方式可以解決問題！
(1) 跟后端溝通，讓他增加一個接口
嗯，我們復習一下什么是VO對象。
VO（View Object）：視圖對象，用於展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。
那可以讓后端封裝一個接口，后端幫你把數據拼裝好，提供API如下
GET /bookVOs/1
這樣直接返回的結果就是
[{
"id": 1,
"bookname": Harry Potter,
"price": 56.00,
"author_name": J. K. Rowling
}]
當然，因為你這是臨時讓后端加接口，可能會有如下情形產生
OK，回到正題，這樣做的缺點主要有兩個
- 前后端強耦合在一起，前端界面發生變動，后端VO對象跟着一起變
- 如果BookVO對象在手機端、PC端、APP端的顯示內容都不一樣，你可能在項目中會有BookPcVO類、BookH5VO類、BookAppVO類，VO類大大膨脹！
(2) 自己做適配
這個也很簡單，前端獲得結果后，取出author_id: 2這條記錄，然后再去調用地址
GET /authors/2
得到結果，然后進行組裝顯示！
當然，這個時候會有如下情形產生(這就是我注孤生的原因！)
當然，這種做法的缺點也很明顯
- 返回了一堆前端並不需要的數據
- 徒增前后端的交互次數
ok，通過上面的描述，大家應該能體會到Rest的缺點:REST接口時返回的數據格式、數據類型都是后端預先定義好的，如果返回的數據格式並不是調用者所期望的，調用者在處理上比較麻煩！
那么，有沒有辦法讓前端自定靈活的使用查詢語句，自己想撈什么數據就撈什么數據呢？
有的，那就是Graphql！
Graphql的出現
Graphql其實要這樣理解
Graphql=grap(圖)+query+lanage
是一種基於圖的查詢語言！那么，這張圖長什么樣？
OK，首先你要聲明一下，你的圖結構，嗯，用的就是Graphql的語法啦，像下面這樣
type Book {
id: Int
bookname: String
authors: [Author]
}
type Author {
id: Int
name: String
age: String
}
type Query {
getBook(id: Int): Book
}
schema {
query: Query
}
對上面的語句進行一下解釋。這里一共聲明了三個類Book、Author、Query！其實，Book和Author大家都可以猜都出來是指啥，需要注意的一點是authors: [Author]這個地方，用了一個[]的語法，這代表Author是一個數組！
唯一需要說明的是，Query是什么鬼？
Query在這兒表明了該類型是這張圖的入口，也就是根節點！我們的查詢必須從根節點里的屬性開始！這里我為了便於說明，只列了一個屬性，也就是getBook，該屬性是入口，必須從入口開始查！
那么，生成的圖是長下面這樣的
這里還有一個Resolver的概念，就是說，GragphQL解析到getBook方法的時候，方法體內容是啥？是在Resovler中定義的，我這里就不貼配置了，感興趣的可以自己去官網閱讀！
OK,接下來就是第二個問題，怎么查？
根據上面我說的，只能從根開始，根是getBook，那語句怎么寫呢？如下所示
那你想加個字段，顯示作者名字呢？直接像下面這么寫
采用這種語法結構，后端的數據模型就變成了一張圖，前端可以定制化自己的輸出結構，同時可以減少前后端的溝通成本，提高靈活性！
一些疑問
(1)java語言中，對Graphql的支持如何？
在java中，有個jar包為graphql-java-tools提供了對Java的支持。
另外，考慮到現在大多是springboot項目，有大神封裝好了starter包，供你們的springboot項目使用！
只需在項目中引入
<!-- graphql -->
<dependency>
<groupId>com.graphql-java</groupId>
<artifactId>graphql-spring-boot-starter</artifactId>
<version>4.0.0</version>
</dependency>
<dependency>
<groupId>com.graphql-java</groupId>
<artifactId>graphql-java-tools</artifactId>
<version>4.3.0</version>
</dependency>
即可讓你的springboot項目擁有graphql的功能，非常方便！
(2)這樣做不會加重前后端工作量么？
說句實在話，摸着良心說，前期確實加重了前后端的工作量！
對前端而言：需要去了解Graphql的語法！
對后端而言：不僅需要了解Graphql的語法，還需要去編寫Schema和Resovler！
所以短期內，確實增加了工作量！但是從長遠來看，同時降低了前后端的工作量！第一，前端不用了解后端的數據結構，GraphQL自己生成可交互式的接口文檔，前端可以自己測試調用
第二，后端不用在編寫什么接口文檔，GrapQL自動幫你生成，用起來非常舒心！
總結
本文介紹了Rest的缺點，以及Graphql的基本知識，希望大家有所收獲！