graphql有哪些特性

graphql 是一種用于 API 的查詢語言，對你的 API 中的數(shù)據提供了一套易于理解的完整描述，使得客戶端能夠準確地獲得它需要的數(shù)據，減少數(shù)據的冗余。

對比 Rest API

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

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

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

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

• 關注于對象與資源
• 會有多種不同的客戶端
• 需要良好的可發(fā)現(xiàn)性和文檔
• 這種情景使用 REST + JSON API 可能會更好。

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

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

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

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

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

• 消息密集型
• 期望系統(tǒng)開銷較低
• 這種情景使用 RPC 或者 REST 均可。

5、如果是 Data or Mobile API，這類 API 的特點是：

• 數(shù)據類型是具有圖狀的特點
• 希望對于高延遲場景可以有更好的優(yōu)化
• 這種場景無疑 GraphQL 是最好的選擇。

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

{
hero {
name
}
}

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

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

這是 GraphQL 最重要的特性，因為這樣一來，你就總是能得到你想要的數(shù)據，而服務器也準確地知道客戶端請求的字段。并且在GraphQL中查詢是可交互的，你可以按你喜歡來改變查詢，然后看看新的結果。

在查詢時可以添加上參數(shù)，結果也會顯得更有趣。參數(shù)可以是多種不同的類型。GraphQL 自帶一套默認類型，但是 GraphQL 服務器可以聲明一套自己的定制類型，只要能序列化成你的傳輸格式即可。

例如，有如下查詢：

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

其結果為：

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

在類似 REST 的系統(tǒng)中，你只能傳遞一組簡單參數(shù) —— 請求中的 query 參數(shù)和 URL 段。但是在 GraphQL 中，每一個字段和嵌套對象都能有自己的一組參數(shù)，從而使得 GraphQL 可以完美替代多次 API 獲取請求。甚至你也可以給 標量（scalar）字段傳遞參數(shù)，用于實現(xiàn)服務端的一次轉換，而不用每個客戶端分別轉換。