【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】
