GraphQL,API的新工具规范

【51CTO.com快译】GraphQL服务端向客户端提供了一种预定义式的架构。它支持从服务端检索某种模型的数据。其结构模式充当了服务端和客户端之间的连接器,同时也定义了访问信息的过程。

GraphQL架构的各种基本元素,都是以SDL(Schema Definition Language,模式定义语言)记录下来的。这些记录解释了哪些对象可以在特定的服务端被请求,它们拥有哪些字段,允许请求获取哪些类型的数据,以及这些类型之间的关系。

为了确保服务端能够响应某种查询,并保证客户端可以根据既定的模式来验证该查询,您可以开发出特有的GraphQL模式,并使用任何一种编程语言来创建对应的接口。籍此,您便可以根据与结果相匹配的GraphQL查询格式,来预测对应的结果。此外,GraphQL模式还能够避免出现诸如结构错误或数据不可用,等异常情况。

可见,只有在GraphQL的相关操作到达后端应用之后,针对完整架构的解析才能进行,而前端应用的数据也才能被准确地解析出来。

GraphQL操作

目前,GraphQL具有如下三种主要操作方式:

  • 查询读取数据
  • 写入数据的变化
  • 随着时间的推移,自动接收实时数据

GraphQL将全量数据集的方式改进为:仅在同一个请求中就实现数据的查询与接受。这种客户端驱动式(client-driven)的方法备受开发人员的推崇。至于返回的数据类型,GraphQL将此类数据控制权交付给了客户端。

而对于REST而言,由于服务端预先定义好了所有资源的可用数据。因此就算只需要一部分数据,客户端也必须通过重复的网络请求,来获取资源中的全量信息。这就产生了所谓的过度获取(over-fetching)的问题。

GraphQL与REST的优势相比

GraphQL和REST都是构建和使用API​​所需的规范。这两种技术的共同特点是:在通过发送查询请求来检索资源时,它们都可以在请求中返回JSON数据。

此外,它们都可以通过HTTP的方式进行操作。而由于它们都充当了调用服务端函数的数据入口,因此REST和GraphQL的端点字段有着许多相似之处。

虽然有着上述共同点,但是它们的概念模型却有着明显的差异。GraphQL建立在图形基础上的;而REST则建立在文件之上。这就导致了开发人员在构建和使用API​​上会产生不同的体验。

就运行速度而言,GrapgQL更快。用户可以通过选择需要在其上运行的查询字段数量,来减少请求以及实际消耗的时间。这便是GraphQL API比REST API更受欢迎的原因之一。此外还有:

1)是多面(Multifaceted)系统和微服务的绝配

GraphQL可以通过在API后端集成多个系统,来统一和隐藏实现的复杂性。GraphQL的服务端负责从当前的系统中获取数据,然后将其打包成为GraphQL的响应格式。这对于多年来一直需要通过大量扩展第三方API的旧版架构来说,是尤为重要的。同时,GraphQL也减少了不少的维护负担。

通过将单体的后端应用迁移到微服务的架构之中,我们可以把多个微服务合并到GraphQL的模式里,以实现它们之间的通信。此外,即使每一个微服务都定义了自己的GraphQL模式,并具有自己的GraphQL端点,我们也可以通过某一个GraphQL API网关,来将其整合为全局模式。

2)通过单个API的调用来获取信息

由于REST分散在各个端点处,因此开发人员往往需要合并多个端点,来收集所有需要的数据。而对于专注于主要任务的GraphQL而言,开发人员仅需一个API调用,便可以请求到各种所需的信息。

3)恰当获取数据

以REST方式获取响应数据有一个不稳定的因素:数据要么太少要么过多,因此,开发人员不得不执行多个查询请求。而由于GraphQL能够通过单个请求,获取确切的数据,因此它有效地解决了此类问题。

4)按需调整请求

通常,开发人员只能通过REST API文档,来请求特定端点的相关功能与参数。而GraphQL能够描述数据的类型、字段以及它们之间的交互点。因此GraphQL开发人员可以自定义请求,并访问各种必要的信息。

5)开箱即用的身份验证和类型检查

GraphQL的自省(introspection)功能使得用户可以检测类型、并查找模式,进而确保应用程序只采用正确的结构,去请求所需的内容。

此外,开发人员还可以借助GraphQL IDE,将新的字段添加到当前的查询之中,而无需额外地验证数据格式。他们需要做的只是编写解析器。

6)自动生成API文档

由于文档与代码紧密相关,因此GraphQL API的变更能够保持同步。一旦有某个字段、查询或类型发生了改变,其对应的文档将自动触发修改。

7)API的迭代不产生新版本

作为一款不断迭代的API,REST提供了多个不同的API版本。这就意味着:开发人员必须保留旧的版本,直至迁移到新的版本上。

而GraphQL则可以从架构中直接删除“老化”的字段,而不会影响到将来对于现有方式的查询。此举确保了GraphQL在不断迭代的过程中,仍然可以不间断地访问到目标应用的新功能,同时也能够保持服务端代码的整洁与易维护性。

8)代码共享

如果需要代码重用,那些在GraphQL多个查询中所用到的字段,可以实现高级别的组件共享。这些代码段可以让用户在保持相同的架构字段的基础上,访问到各种类型的数据。

9)详细的错误消息

为了能够准确地定位到程序中出现的问题,以及对应的解决方案,REST需要通过检查HTTP头,来获取响应状态。而在GraphQL中,如果处理过程发生了错误,则后端会提供包含有解析程序的详细消息,以准确定位查询失败的确切部分。

10)权限

相较于REST的简单视图,开发人员可以在创建GraphQL模式时,选择需要全面展示的功能,及其具体的工作方式。因此,用户能够根据具体情况,细粒度地显示不同程度的视图。

总结

我们不能武断地认为:作为工具的GraphQL将可以完全替代作为架构模式的REST。到底哪一个更合适您手头的项目,还是取决于特定的API交互模式,以及具体的使用场景。

原文标题:GraphQL: The Future of APIs,作者:Noa James

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑:庞桂玉 TEL:(010)68476606】