靈活的API查詢語言——GraphQL

本文簡單的介紹了 GraphQL，但願可以幫助你們對這個方便的查詢語言有一個簡單的認識

GraphQL 是什麼

GraphQL 是一種 API 查詢語言，是一個對自定義類型系統執行查詢的服務端運行環境。它至關於客戶端和服務器之間的中介，將客戶端發來的所需數據的請求處理以後在一次請求之中就能得到符合客戶端需求的響應數據。它還有個好處就是它是一種看成一種組織，管理數據的能力來使用，而不綁定在什麼數據庫上面，數據存在於哪裏與它無關。

對比 Rest API

Rest API 是和 GraphQL 同類的用於查詢的語言。Rest 把每一個資源都用一個 URL 表示，訪問這個 URL 就可以獲得一份 JSON 格式的數據響應，可是這有一個缺點，你可能會獲得與需求不相關的數據。而 GraphQL 則不會，發送過去的請求中指定了須要哪一個資源，舉個簡單的例子，你須要這本書的做者的姓資源，那麼 Rest API 會把把做者的名字也發給你，由於你是經過訪問做者的信息的 URL 來得到姓的，而 GraphQL 則會只把須要的信息發過來，換句話說，須要什麼資源是用戶來決定的。

RPC vs REST vs GraphQL（參考資料點擊這裏）

在合適的時候選擇合適的工具是重要的，下面則列舉了在一些場景下最好使用什麼工具來做爲參考

一、若是是 Management API，這類 API 的特色以下：

• 關注於對象與資源
• 會有多種不一樣的客戶端
• 須要良好的可發現性和文檔
• 這種情景使用 REST + JSON API 可能會更好。

二、若是是 Command or Action API，這類 API 的特色以下：

• 面向動做或者指令
• 僅須要簡單的交互
• 這種狀況使用 RPC 就足夠了。

三、若是是 Internal Micro Services API，這類 API 的特色以下：

• 消息密集型
• 對系統性能有較高要求
• 這種情景仍然建議使用 RPC。

四、若是是 Micro Services API，這類 API 的特色以下：

• 消息密集型
• 指望系統開銷較低
• 這種情景使用 RPC 或者 REST 都可。

五、若是是 Data or Mobile API，這類 API 的特色是：

• 數據類型是具備圖狀的特色
• 但願對於高延遲場景能夠有更好的優化
• 這種場景無疑 GraphQL 是最好的選擇。

GraphQL 的查詢與變動——如何查詢 GraphQL 服務器
以一個查詢結果爲例：

{
hero {
name
}
}

該查詢將會得到一個與其結構幾乎同樣的結果：

{
"data": {
"hero": {
"name": "R2-D2"
}
}
}

這是 GraphQL 最重要的特性，由於這樣一來，你就老是能獲得你想要的數據，而服務器也準確地知道客戶端請求的字段。而且在GraphQL中查詢是可交互的，你能夠按你喜歡來改變查詢，而後看看新的結果。

在查詢時能夠添加上參數，結果也會顯得更有趣。參數能夠是多種不一樣的類型。GraphQL 自帶一套默認類型，可是 GraphQL 服務器能夠聲明一套本身的定製類型，只要能序列化成你的傳輸格式便可。

例如，有以下查詢：

{
human(id: "1000") {
name
height
}
}

其結果爲：

{
"data": {
"human": {
"name": "Luke Skywalker",
"height": 1.72
}
}
}

在相似 REST 的系統中，你只能傳遞一組簡單參數 —— 請求中的 query 參數和 URL 段。可是在 GraphQL 中，每個字段和嵌套對象都能有本身的一組參數，從而使得 GraphQL 能夠完美替代屢次 API 獲取請求。甚至你也能夠給 標量（scalar）字段傳遞參數，用於實現服務端的一次轉換，而不用每一個客戶端分別轉換。