Github 為什麼開放了一套 GraphQL 版本的 API？

背景

github 宣布開放了一套使用 graphql 開發的公共 api。

github 的 rest api 已經非常完善，設計得很優秀，很多公司開發自己的 rest api 時都會參考 github，也有很多愛好者寫了非常豐富的教程。

graphql 的核心是一套資料查詢語言的規範，是 facebook 在2012年開發的，2015年開源，facebook 内部已經廣泛應用，用于替代 rest。

github 為什麼選擇 graphql？這是很多使用者關心的問題，github 對此做了解釋。

rest api 有什麼問題？

首要問題就是擴充性方面，随着 api 的不斷發展，會變得越來越臃腫

rest api 的方式是：server定義一系列的接口，client調用自己需要的接口，擷取目标資料進行整合

例如使用者接口，剛開始時，傳回的資訊會比較少，例如隻有 id,name

後來使用者的資訊增加了，就在使用者接口中傳回更多的資訊，例如 id,name,age,city,addr,email,headimage,nick

但可能很多client隻是想擷取其中少部分資訊，如 name,headimage，卻必須得到所有的使用者資訊，然後從中提取自己想要的

這個情況會增加網絡傳輸量，并且不便于client處理資料

還有一個不友善的地方，例如client在某個需求中，可能需要調用多個獨立的 api 才能擷取到足夠的資料

例如client要顯示一篇文章的内容，同時要顯示評論、作者資訊，那麼就可能需要調用文章接口、評論接口、使用者接口

這種方式非常不靈活

github 還遇到其他一些 rest api 不好處理的問題，例如

想要確定client提供的參數的類型安全；想要從代碼生成文檔；想要識别每個端點的oauth請求範圍 ……

使用 graphql 有什麼好處？

graphql 簡單來說就是：取哪些資料是由client來決定

rest 中，給哪些資料是server決定的，client隻能從中挑選，如果a接口中的資料不夠，再請求b接口，然後從他們傳回的資料中挑出自己需要的

graphql 中，client 直接對 server說想要什麼資料，server負責精确的傳回目标資料

例如，你想要擷取使用者的幾個屬性資訊，你的 graphql 請求就是這樣的

傳回的響應資訊如下

再看一個更複雜的例子，例如你想知道你給多少個項目點亮過星星、最初3個項目的名字、及他們star fork watcher的總數可以看到，傳回的 json 資料中，key value 是和請求完全一緻的

graphql 請求就是這樣的

響應資訊如下

graphql 還有很多其他的特點，例如你隻需要一個請求，就可以得到所有需要的資料

批量請求，可以定義兩個獨立請求的依賴關系，高效的擷取資料

建立訂閱，client 可以收到新的資料

資料延遲，可以對響應中一部分資料辨別為時間不敏感