GraphQL，API的新工具规范

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，API的新工具规范
URL分享：http://www.shufengxianlan.com/qtweb/news34/50484.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联