靈活的API查詢語言——GraphQL

安全劍客發表於2018-11-07
API

本文簡單的介紹了 GraphQL，希望能夠幫助大家對這個方便的查詢語言有一個簡單的認識

GraphQL 是什麼

GraphQL 是一種 API 查詢語言，是一個對自定義型別系統執行查詢的服務端執行環境。它相當於客戶端和伺服器之間的中介，將客戶端發來的所需資料的請求處理之後在一次請求之中就能獲得符合客戶端需求的響應資料。它還有個好處就是它是一種當作一種組織，管理資料的能力來使用，而不繫結在什麼資料庫上面，資料存在於哪裡與它無關。

對比 Rest API

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

RPC vs REST vs GraphQL（ 參考資料點選這裡 ）

靈活的API查詢語言——GraphQL靈活的API查詢語言——GraphQL

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

1、如果是 Management API，這類 API 的特點如下：

  • 關注於物件與資源

  • 會有多種不同的客戶端

  • 需要良好的可發現性和文件

  • 這種情景使用 REST + JSON API 可能會更好。

2、如果是 Command or Action API，這類 API 的特點如下：

  • 面向動作或者指令

  • 僅需要簡單的互動

  • 這種情況使用 RPC 就足夠了。

3、如果是 Internal Micro Services API，這類 API 的特點如下：

  • 訊息密集型

  • 對系統效能有較高要求

  • 這種情景仍然建議使用 RPC。

4、如果是 Micro Services API，這類 API 的特點如下：

  • 訊息密集型

  • 期望系統開銷較低

  • 這種情景使用 RPC 或者 REST 均可。

5、如果是 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）欄位傳遞引數，用於實現服務端的一次轉換，而不用每個客戶端分別轉換。

更多GrophQL的型別系統請點選這裡


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2218991/，如需轉載，請註明出處，否則將追究法律責任。

相關文章