GraphQL：API的未来
极客时间编辑部
讲述：初明明大小：4.72M时长：05:10
当谈起 API 设计时，人们首先会想到 REST API，它是标准化的工具，通过 URL 的方式从服务器上获取数据。但随着国外一些大公司从 RESTful API 转移到 GraphQL API 后，有观点称 GraphQL 才是 API 的未来。
简单来说，GraphQL 是一个开源的查询语言和协议 API。它与 REST 都是是用来构建和使用 API 的规范，二者有很多相同或相似之处。那么 GraphQL API 与 RESTful API 相比，优势在哪呢？近日，移动应用开发者诺亚·詹姆斯（Noa James）总结出使用了 GraphQL API 之后所带来的一些较为明显的好处。
1. 与多系统（Multifaceted Systems）和微服务能较好匹配
GraphQL 将多个系统集成到 API 中，从而形成了统一的 API 接口，并且能够将各个系统的复杂性隐藏在 API 背后。GraphQL 服务器的任务就是从当前这些系统中获取数据，并且将数据打包放入 GraphQL 返回的数据格式中。
许多第三方 API 和传统的基础设施在这些年经历了大举扩张，对于这样的 API 和基础设施，GraphQL 与多系统的匹配性尤其重要，因为匹配得不好就会带来维护负担。
2. 通过单一的 API 调用获取信息
如果使用 REST API，那么开发者需要把多个接入点合并起来才能收集到所有需要的数据，因为 REST 散落分布在多个独立的接入点上。
GraphQL 与 REST 的主要区别就在这里。开发者仅仅通过一个 API 调用就可以请求到所需信息，而 GraphQL 会专注于主体任务。
3. 不会存在过多或者过少获取数据的问题
从 REST 收到的响应来看，有一个不稳定的因素，即收到的信息里要么信息不足，要么信息冗余，这样就不可避免地需要再发出一次请求。而 GraphQL 就解决了这个问题，因为它只需请求一次，就能够获取所需的精确的数据信息。
4. 根据你的需求自定义请求格式
开发者按照 REST API 文档描述发出请求时，只能请求一些特定的接入点、相关函数和参数等。
而另一方面，GraphQL 可以描述数据类型、字段以及它们之间的任何交互连接点。这就允许 GraphQL 开发者自定义请求格式来获取必要的信息。
5. 即时的身份验证和类型检查机制
GraphQL 的自省特性能够为开发者导航到某个数据类型，找到相应的数据模式，确保 App 采用正确的结构发出有效的请求。
虽说 GraphQL 会检查已有模式的结构正确性，但是开发者想为当前查询添加新的字段也是可以的，开发者可以通过 GraphQL IDE 做到这点，他们不用去进一步验证数据格式的合法性，只需要为新数据结构编写解析器即可。
6. API 文档的自动生成
GraphQL 的文档和 API 修改是同步进行的，因为 GraphQL 文档和其代码联系紧密。于是，代码修改，哪怕是一个字段、一次查询或者是数据类型的修改，也会触发文档的自动更新。
7. API 的进化不用考虑版本兼容性问题
REST 提供了好几个 API 版本，它的 API 在不断进化修改，这意味着开发者们如果不想只支持新版本的 API，那他们就得保留 API 的旧版本。GraphQL 就省略了该步骤，开发者们不用保留 API 旧版本，因为老旧的字段可以从模式中移除，而不会在今后影响到以前已有的查询。
这就确保了开发者可以在 GraphQL 的进化版本中连续获取到 App 的新特性，服务端的代码也因此变得更加干净和容易维护。
8. 代码分享
如果有重用的需求，那么可以在更高的组件级别，对 GraphQL 多个查询中使用的字段进行共享。这些所谓的片段能够让你访问各种类型的数据，同时仍然遵守相同的模式字段。
9. 详细的报错信息
要确定什么地方出了问题，以及需要做什么来应对问题时，在 REST 中只要检查 HTTP 头的响应状态就足够了。但是，在 GraphQL 中，如果在处理数据时报错了，后端会提供一条详细的信息，因为后端带有解析器。这些信息会提供查询中错误所在的精确位置。
10. 权限
在创建 GraphQL 模式时，可以选择展示哪些函数和操作。和 REST 视图功能相比，这不是好不好的问题，而是有无的差别。所以这里的关键是，各个视图应当知道在特定场景中哪些东西是需要显示的，哪些是不用显示的。
文章最后，诺亚·詹姆斯总结道，我们不能说 GraphQL 是要完全取代 REST，因为前者只是一个工具，而 REST 是一种架构模式。具体哪一个更合适，将取决于它们独特的交互场景。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
文武木子对前端要求过高🌝🌝
七进制拿着这个和公司目前的应用进行了一下匹配，发现要使用起来相当的困难。还不如最原始的接口方式来的方便
JackSparrow这个东西推动很难的 特别是国内环境 不稳定的需求 大程度上会引发难于预期的修改 在下不才尝试推动过 结果惨淡收场 希望大厂能够帮忙推动吧 毕竟领导就学大厂
乐只君子GraphQL 对前端的知识储备要求更高。不然遇到复杂查询要慢死
NullPointer好像说的rest一无是处？1
收起评论