Github 为什么开放了一套 GraphQL 版本的 API?

局长
 局长
发布于 2016年10月23日
收藏 75

本周日,来 OSC·年终盛典收割技术干货,get新技能!!>>>

背景

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 请求就是这样的

{
 viewer {
   login
   bio
   location
   isBountyHunter
 }
}

返回的响应信息如下

{
 "data": {
   "viewer": {
     "login": "octocat",
     "bio": "I've been around the world, from London to the Bay.",
     "location": "San Francisco, CA",
     "isBountyHunter": true
   }
 }
}

再看一个更复杂的例子,例如你想知道你给多少个项目点亮过星星、最初3个项目的名字、及他们star fork watcher的总数可以看到,返回的 JSON 数据中,key value 是和请求完全一致的

GraphQL 请求就是这样的

{
 viewer {
   login
   starredRepositories {
     totalCount
   }
   repositories(first: 3) {
     edges {
       node {
         name
         stargazers {
           totalCount
         }
         forks {
           totalCount
         }
         watchers {
           totalCount
         }
         issues(states:[OPEN]) {
           totalCount
         }
       }
     }
   }
 }
}

响应信息如下

{  
 "data":{  
   "viewer":{  
     "login": "octocat",
     "starredRepositories": {
       "totalCount": 131
     },
     "repositories":{
       "edges":[
         {
           "node":{
             "name":"octokit.rb",
             "stargazers":{
               "totalCount": 17
             },
             "forks":{
               "totalCount": 3
             },
             "watchers":{
               "totalCount": 3
             },
             "issues": {
               "totalCount": 1
             }
           }
         },
         {  
           "node":{  
             "name":"octokit.objc",
             "stargazers":{
               "totalCount": 2
             },
             "forks":{
               "totalCount": 0
             },
             "watchers":{
               "totalCount": 1
             },
             "issues": {
               "totalCount": 10
             }
           }
         },
         {
           "node":{
             "name":"octokit.net",
             "stargazers":{
               "totalCount": 19
             },
             "forks":{
               "totalCount": 7
             },
             "watchers":{
               "totalCount": 3
             },
             "issues": {
               "totalCount": 4
             }
           }
         }
       ]
     }
   }
 }
}

GraphQL 还有很多其他的特点,例如你只需要一个请求,就可以得到所有需要的数据

  • 批量请求,可以定义两个独立请求的依赖关系,高效的获取数据

  • 创建订阅,client 可以收到新的数据

  • 数据延迟,可以对响应中一部分数据标识为时间不敏感

小结

不只是 Github,还有很多大公司已经使用 GraphQL,例如 Pinterest, Coursera, Shopify

Github 也表达了对 GraphQL API 的重视,接下来会持续完善,使其更加灵活

文章出处:性能与架构微信订阅号

作者:杜亦舒

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:Github 为什么开放了一套 GraphQL 版本的 API?
加载中

精彩评论

孤独的探索号
孤独的探索号

引用来自“Qiujuer”的评论

结构很不错,但是实现成本较高,商业采用有待考究。
APIJSON几乎无迁移成本,而且比它简单易用。已有仿QQ空间和微信朋友圈的Demo
https://github.com/TommyLemon/APIJSON

最新评论(17

孤独的探索号
孤独的探索号

引用来自“Qiujuer”的评论

结构很不错,但是实现成本较高,商业采用有待考究。
APIJSON几乎无迁移成本,而且比它简单易用。已有仿QQ空间和微信朋友圈的Demo
https://github.com/TommyLemon/APIJSON
孤独的探索号
孤独的探索号

引用来自“lxbzmy”的评论

GraphQL 很坑的哦,和REST一样坑。客户端想要什么数据就整合给他,通常很难。
服务端程序不好测试的。
APIJSON服务端只需要调用Parer.parse(...)一行代码就行,log很精准丰富,客户端请求也很简单易用。
https://github.com/TommyLemon/APIJSON
X
Xiao_f

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统

引用来自“南漂一卒”的评论

HTTP/1.1 正式发布于 1999年中,RESTful API 论文发表于 2000年,不要乱讲~
DELETE PUT 1.0时就定义了哦,HTTP当初设计的时候还完全是静态页面的思想主导,作者万万没想到http能承载起当今复杂的webapp,所以资源主导api设计的适用范围是有限的,根据系统类型选择api设计方法很重要,不能一概而论,只能说互联网最擅长炒概念,很多公司用REST甚至是为了卖点宣传产品,这不是本末倒置?
lxbzmy
lxbzmy
GraphQL 很坑的哦,和REST一样坑。客户端想要什么数据就整合给他,通常很难。
服务端程序不好测试的。
Qiujuer
Qiujuer
结构很不错,但是实现成本较高,商业采用有待考究。
吾爱
吾爱
关注一下
iBoxDB
iBoxDB
如果用于外网Restful更容易权限控制,如果随意让客户端查询,不注意就会被读取到重要数据。
南漂一卒
南漂一卒

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
HTTP/1.1 正式发布于 1999年中,RESTful API 论文发表于 2000年,不要乱讲~
nicozhang
nicozhang

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
如果rest不合适,有什么合适的吗?
X
Xiao_f
REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
返回顶部
顶部