GitHub宣布開放壹套使用GraphQL開發的公共API。
GitHub的REST API非常完善，設計得很好。很多公司在開發自己的REST API時都會參考GitHub，也有很多粉絲寫了非常豐富的教程。
GraphQL的核心是壹套數據查詢語言規範，由臉書於2012開發，2015開放。在臉書，它已被廣泛用於替代REST。
GitHub為什麽選擇GraphQL？這是很多用戶關心的問題，Github對此進行了解釋。
REST API有什麽問題？
第壹個問題是可擴展性，隨著API的不斷發展，可擴展性會越來越臃腫。
REST API的方式是:服務器端定義壹系列接口，客戶端調用需要的接口獲取目標數據進行集成。
例如，用戶界面起初會返回較少的信息，比如只有id、姓名。
後來，當用戶的信息增加時，用戶界面中返回更多的信息，如ID、姓名、年齡、城市、地址、電子郵件、頭像和昵稱。
但是可能很多客戶端只是想獲得壹小部分信息，比如姓名名稱，頭像，但是他們必須獲得所有的用戶信息，然後從中提取他們想要的。
這種情況會增加網絡傳輸，給客戶端處理數據帶來不便。
還有壹個不便。例如，在某個需求中，客戶端可能需要調用多個獨立的API來獲取足夠的數據。
例如，如果客戶端想要顯示壹篇文章的內容，以及評論和作者信息，它可能需要調用文章接口、評論接口和用戶接口。
這種方法非常不靈活。
GitHub還會遇到壹些其他REST API不容易處理的問題，比如
您希望確保客戶端提供的參數的類型安全；想要從代碼生成文檔；想要識別每個端點的OAuth請求範圍...
使用GraphQL有什麽好處？
GraphQL很簡單:由客戶端決定獲取哪些數據。
在REST中，服務器決定給出哪些數據，客戶端只能從中選擇。如果接口A中沒有足夠的數據，它會再次請求接口B，然後從它們返回的數據中選擇它需要的數據。
在GraphQL中，客戶端直接告訴服務器想要什麽數據，服務器負責準確返回目標數據。
比如妳想獲取用戶的幾個屬性信息，妳的GraphQL請求是這樣的。
{
查看器{
登錄
個人簡歷
位置
isBountyHunter
}
}
返回的響應信息如下
{
"數據":{
"查看器":{
“登錄”:“octocat”，
《傳記》:“我走遍了世界，從倫敦到海灣。”,
“位置”:“加利福尼亞州舊金山”，
“isBountyHunter”:真
}
}
}
讓我們看壹個更復雜的例子。比如妳想知道妳點亮了多少個項目，前三個項目的名稱，以及它們的星叉守望者總數。可以看到返回的JSON數據與請求完全壹致。
GraphQL請求就是這樣的。
{
查看器{
登錄
星號倉庫{
總數
}
存儲庫(第壹個:3個){
邊緣{
節點{
名字
觀星者{
總數
}
叉子{
總數
}
觀察者{
總數
}
問題(狀態:[打開]) {
總數
}
}
}
}
}
}
響應信息如下
{
"數據":{
"查看器":{
“登錄”:“octocat”，
" starredRepositories": {
【總數】:131
},
“存儲庫”:{
"邊緣":[
{
"節點":{
"名稱":" octokit.rb "，
"觀星者":{
【總數】:17
},
"叉子":{
“總數”:3
},
"觀察者":{
“總數”:3
},
"問題":{
"總數":1
}
}
},
{
"節點":{
"名稱":" octokit.objc "，
"觀星者":{
“總數”:2
},
"叉子":{
“總數”:0
},
"觀察者":{
"總數":1
},
"問題":{
【總數】:10
}
}
},
{
"節點":{
【名稱】:“octokit.net”，
"觀星者":{
【總數】:19
},
"叉子":{
“總數”:7
},
"觀察者":{
“總數”:3
},
"問題":{
“總數”:4
}
}
}
]
}
}
}
}
GraphQL還有很多其他的特性，比如壹個請求就可以獲得妳需要的所有數據。
批量請求可以定義兩個獨立請求的依賴關系，高效地獲取數據。
創建訂閱，以便客戶端可以接收新數據。
數據延遲，可能對響應中的某些數據不敏感。
總結
不僅是Github，很多大公司都用過GraphQL，比如Pinterest，Coursera，Shopify。
Github也表示了對GraphQL API的重視，並將繼續對其進行改進，使其更加靈活。