返回上乙個版本 GraphQL 概念與測試（上）

graphql是近幾年突然興起的一種介面定義模式，那麼它有什麼特點？相對於傳統的介面定義又有什麼優勢呢？

官網：

例如對於抖音中使用者這個模型，在詳情頁、好友列表頁、好友推薦頁、下拉選擇列表中所需的字段屬性都不一樣，有的多有的少。

傳統的restful風格的介面要麼用乙個完整的介面返回全部資料(浪費資料)，要麼拆分多個介面(增加前後端成本)。

然而graphql可以只通過乙個請求，解決以上問題。graphql通過引數控制返回字段，你需要什麼字段，就給你什麼字段。

如何定義自己的graphql介面

首先，你需要使用graphql的模型定義語言(sdl)來對你的模型進行定義，例如圖中右下角對maindomain的定義。

其次，你需要對入口進行定義，例如圖中右上角的query，這就是請求maindomain的介面表達。

然後，你就可以按照圖中左側的方式來進行graphql請求了；這個字串理論上是需要放在http post請求體中，對graphql的介面服務進行請求；而請求路徑一般就是/graphql，不再需要像restful那樣預設請求url。

如果想要使用引數化來傳遞入參，可以使用下圖中右側這樣的形式；可以看到最下面對 maindomainid 進行了引數化，而上方則使用$maindomainid進行了輸入。

當然，上面舉的例子是query方法，也就是查詢方法；也可以定義mutation方法，也就是對模型資料進行修改(增刪改)。

graphql的特性

1. 需要什麼，就給你什麼

請求中的graphql字串和返回字段一一對應；如果只需要id和name，就是需要只請求id和name，那麼就只返回id，name。

需要其他字段，就拓撲請求字串即可，如下圖。

2. 一次請求全部所需資料

如果把整個系統的資料看做乙個有向圖，那麼graphql查詢請求的做法，實際等於是：

3. 前後端解耦，相容新舊版本介面

當新版本加了乙個返回字段，傳給舊版本的前端可能會引發未知的問題。

在restful風格的介面中，只要後端返回了，前端就會收到。而graphql的介面，由前端來控制返回字段，於是：後端新版本增加的字段，舊版本的前端是可以完全無感知的。

額外地，如果這個字段本身就在原有的後端資料模型中，那後端完全不需要改碼，前端請求時增加字段即可；如果新版本前端展示時減少了乙個字段，前端請求時去掉該欄位即可，後端甚至不一定需要進行改動。

4. graphql is doc, and code

graphql本身支援直接啟動playground，可以直接當做頁面除錯入口，或者介面文件展示頁面；許多語言也支援由graphql模型定義直接生成基礎**。這樣，graphql的定義既可以快速形成介面文件，也可以快速形成**。

值得注意的是，最新版本的postman也已經開始graphql風格的請求了。

graphql vs restful

graphql更傾向於描述模型與模型之間的關係，建立他們之間的連線。

這樣帶來的好處有：

這樣帶來的壞處：

好的，關於graphql的基礎知識和特性就介紹到這裡了。