GraphQL 是一种新的 API 的查询语言,它提供了一种更高效、强大和灵活 API 查询。它 是由 Facebook 开发和开源,目前由来自世界各地的大公司和个人维护。GraphQL 对API 中的数据提供了一套易于理解的完整描述,使得客户端能够准确地获得它需要的数据,而且没有任何冗余。它弥补了 RESTful API(字段冗余,扩展性差、无法聚合 API、无法定义数据 类型、网络请求次数多)等不足。
注意:GraphQL 是 API 的查询语言,而不是数据库。从这个意义上说,它是数据库无关的, 而且可以在使用 API 的任何环境中有效使用,我们可以理解为 GraphQL 是基于 API 之上的一 层封装,目的是为了更好,更灵活的适用于业务的需求变化。
在过去的十多年中,REST 已经成为设计 Web API的标准(虽然只是一个模糊的标准)。 它提供了一些很棒的想法,比如无状态服务器和结构化的资源访问。然而 REST API 表 现得过于僵化,无法跟上访问它们的客户的快速变化的需求。
1. RESTful API 不足
(1). 扩展性(多个终端需要返回不同的字段),单个 RESTful 接口返回数据越来越臃肿。前端对于真正用到的字段是没有直观映像的,仅仅通过 URL 地址,无法预测也无法回忆返回的字段数目和字段是否有效,接口返回 50 个字段,但却只用 5 个字段,造成字段冗余,扩展性差,单个 RESTful 接口返回数据越来越臃肿。
(2). API 聚合问题,某个前端展现,实际需要调用多个独立的 RESTful API 才能获取到足够的数据,导致网络请求次数多。
(3). 前后端字段频繁改动,导致类型不一致,错误的数据类型可能会导致网站出错,尤其是在业务多变的场景中,很难在保证工程质量的同时快速满足业务需求
2. GraphQL 的优点
(1). 吸收了 RESTful API 的特性。
(2). 所见即所得,各种不同的前端框架和平台可以指定自己需要的字段,查询的返回结果就是输 入的查询结构的精确映射。
(3). 客户端可以自定义 API 聚合。
如果设计的数据结构是从属的,直接就能在查询语句中指定,即使数据结构是独 立的,也可以在查询语句中指定上下文,只需要一次网络请求,就能获得资源和子资源的数据。
(4). 代码即是文档。
GraphQL 会把 schema 定义和相关的注释生成可视化的文档,从而使得代码的变更,直接就反映到最新的文档上,避免 RESTful 中手工维护可能会造成代码、 文档不一致的问题。
(5). 参数类型强校验。
RESTful 方案本身没有对参数的类型做规定,往往都需要自行实现参数的校验机制,以确保安全。但 GraphQL 提供了强类型的 schema 机制,从而天然确保了参数类型的合法性。