您应该使用哪个API？

自GraphQL规范于2015年由Facebook开源以来，它已在前端Web开发中迅速普及。为什么这项新技术突然大受欢迎，以及GraphQL与传统REST API相比具有哪些优势？在此博客) * 2 R _中，我们将讨论GraphQL的设计原理，将GraphQL中的请求与REST中的相同请求进行比较，并探究GraphQL与其他体系结构相比的优势。

为了了解GraphQL作为API架构的好p f ? S 8 a I X H处，我们需要O $ + X _讨论AH ~ SPI在客户端-服务器结构中的作用。 API或应用程序编程接口是一种中介，它允许服务器从l o R & 1 K客户端接收对数据的结构化请求，并为所请求的数据发送结构化响应。有多E d 4 + K |种方法可以设计API架构。让我们研究使GraphQL非常适合现代Web应用! Y S I k | b n程序的重要基c % D _ $ B础设计原则。

GraphQL服务器的设计原理

GraP 7 % a 5 ; + ~phQL( f b m /规范概述了5条设计原则，这Q T X T N o使其成为现代前端开发的精心设计的解决方案。让我们研究一下GraphQL的设计原则，以Facebook新闻提要为例。

查询是分层结构的，具有分层和嵌套字段，格式与查询与响应数据一对一匹配。查询和响应的形状像树，可以查询每个项目的其他嵌套字段。在Facebook的新7 D { T闻提要中，此结构允许单个查询返回帖子列表，对每个特定帖子的评_ 8 K + Q 9论，然后对每个评论点赞。
该结构以产1 a A i ; 1 x |品为中心，着重于前端希望如何接收数据，并构建R W 8 u 0交付所需的 / ,运行时。这样一来，Facebook的新k : P _ x F X J o闻提要就可以向后端请求一7 e p 9 Q T个所需的所有数据，然后让服q % c T l c b务器根据GraphQL的规范从不同的端点获取数据。
它使用特定于应用程序的类型系统，使开发人员能够确保查询使用有效类型，并且在执行之前在语法上正# s Y ? u Q s o O确。例如，新闻提要的GraphQL模式将要求字段\"用户\"必须包含字符串，而\"= v Z喜欢\"字段必须包含H B 8 W O数字。如果查询尝试添加其他类型的输入，则GraphQL将在执行查询之前引发错误。
GraphQL查询是在客户端指定的，因此客} } 3 e e v $ P l户端确切知道它将以什么格式接收数据。这意味着，如果Facebook的新闻源对包含用户名，评论和喜欢的帖子v _ t )数据的请求是前端请求的格式，则p k : q可以将其结构化在一个对象中，而不是像其他体J % /系结构那样使用多个单独的数据。
带有GraphQL的服务器结构必须是自省的，或者可由GraphQ{ ^ % & C qL本身查询。这将启用功能强大的开发人员工具J O R a，例如GraphiQL或GraphQL Play- j . :ground，这两种x = |工具都将使Facebook开发人员能够准确查看哪些查询和字段可供他们在服务器中使用。

为了讨论向GraphQL的转变以及这些设计原则如何带来影响开发的利益，我们将首先深入探讨传统的REST API架[ A B ,构，并了解; 4 k该架构可能会在哪些方面出现不足。

传统的RESTful架构

Structure of requests and respon8 + t d )ses in a REST arch8 Z l Z 3 o % @ #itecture

REST体系结构的设计范例集中在分配HTTP请求的方法（GET，POST，PUT，PATCH，DELETE）和@ P z @ 3 q ~ K WURLY U S [ q w p I U端点之间的关系上。在REST体系结构中，方法和端点的每种组合都会评估为不同的封装功能。如果客户端需l U A N要特定端点/方法未提供的数据，则可能需要其他请求。 REST请求| E [ Y t返回的数据格式取决于端点-无法保证该数据将按照前端使用它的方式进行i X ] L 1 G q u格式化。为了使用与默认情况下从端点返回的格式不同的响应数据，必须在客户端编写数据解析= 3 . T + 2 n和操作。

接下来，让我们看一下Graph= : 6 bQL规范与REST的不同之o $ m T b c $处，以及使这种新体系结构成为解决客户端和服| g s : G务器之间的现代数据传递问题的独特解决方案的优势。

GraphQL架构

With GraphQL, clientsB t S } are able to reach many different types of data storage with a2 6 F 8 A single endpoint.

像RESTful API一样，GraphQL API旨在处理HTTP请求并提供对这些请求的响应。但是，相似之处到此结束。在REST APT h S [ I S YI建立在请求方法和端点之间的连接上的情况下，GraphQL API设计为仅使用一个始终通过POS# F k d $T请求查询的端点? e s S 6 # t，通常使用URL yourdomain.com/graphql。

达到GraphQL端点后，客户端请求的负担将完全在请求主体内处理。该请求主体必须遵守GraphQL规范，并且API必须具有适当的服务器端逻辑来处理这些请求并提供适当的响应。与RESTful API相比，这提Z Q 4 X F u = O供了更流畅的客户端体验，后者可能要求客户端对多个数据进行多次请求，并在数据返回后进行操作。为了阐明GraphQL如何做到这一点，让我们细分GraphQL服务器的结构。

GraphQL服务器的结构

启用GraphQL逻辑的服务器端逻辑由具有定D V : N I = G s义的服z R & # g务器功能的文档组成。这些文档包含可执行文件和类型系统定义。顾名思义，类型系统定义定义了可接受的类型，并格式化了每个数据字段的输入和结果。可执行文件包含要处理的可能操作的列表，其中包括操作类型（查询，突变或预订），操作名称，要查询或写入的字段以及选择集，该选择集准确定义了将从中返回什么数据操作。选择集为GraphQL提供了最大的增值-它们允许客户端查询特定的数据集c , S D ~ T ) M，并接收包含所T - M X I请求信息的响应：仅此而已。

有关GraphQL规范的结构和语法的更多信息，请查阅GraphQL的文档。接下来，我们来x v L n 4 w z看一下GraphQL查询的结构。

GraphQL查询的剖析

下面的s q & 8GraphQL查询用于r @ + % J c V B获取特定书籍的数据，包括作者的名字和姓氏。

GET /graphql?query={ books(id:12) { authors { firstName, lastName } title, yearPublished, length } 
{ 
  Query3 = , {                 //  operation type
  books (id:12) {         //  operation endpoint
     authors {            //  requested fix w 6 f relds
        firstName
        lastN` / h { E [ @ame
     } 
     title
     yearPublished    
    }
  }
}

所有这些都可以由Gf 1 6 / ] KraphQL服务器逻辑解析和处理的一个R + r T J 3 9查询完成。将其与REST体系结构中相同请求的 } - k T +结构进行比较时，GraphQL的优势开始变得清晰起来。让我们在下面查看REST请求的结构，然后重点介绍其中的一些区别！

REST请求剖析

为了向q O e H W ) REST APIz + c发出相同的请求，客户端需要首先向终端发出请求，该请求具有返回书籍数据的功能，并将书籍ID作为参数传递：

GET 9 6 n e k I 9 /books/12

该请求可能会返回一个Q H C = #包含该特定书籍的所有数据的对象，例如：

{ 
  “title” : “The Hitchhiker\'s Guide to the Galaxy”,
  “authorID”: 42,
  “yearPublished”; f 4 & ( 2 N : 1978,
  “l@ R 6 I 9 Bength”: 208,
  “genre”: “ScJ ] , x Eience Fiction”
}

与相同的GraphQL查询的响应相比，我们的示例中的响应有两个缺点 # 1 [ ! p I j：

REL C L a s # aST响应包含genre和等字段的额外数据，返回的信息超出了我们的期望。
REST要求我们再提出一个请求，以d = ! E I获取我们实际需要的数据：该特定作者的所有G p # E L M Y书籍。

要获取这些数据，我们需要使用auth@ I corID再次提出$ e = - E 6一个请求：

GET /authors/42

此请求的响应应包含我们正在寻找的所有数据：

{ 
  “firstI M & g Z @ n -NP 4 w D D -ai l # v ?me, & z : / O I” : “Douglas”,
  “lastName”: “Adams”
}

现在我们有了所需的g 6 j t 7 { a p 所有书籍和作者数据，通过响应进行解析的负担就在客户端。前端应用程序现在必须以可用于其所需功能的方式组合来自不同端点的数S c Y Y K据。

考虑到所有因素，GraphQL提供的性^ O 3 f D - L o能优于REST API，可以为前端开发人员带来回报。使用GrZ A C c V k WaphQL规范创建服务器可能需要更多设置和编写预测性服务器端逻辑来解析和处理请求。尽管GraphQL的安装成本可能会高于传统的REST架构，但更具可维护性的代码F m % ~ X，强大的开发工具以及简化的客户端查询的收益通常超过了成本。

(本文翻译自Michele Moody的文章《Grap$ } . +hQL vs. REST API Architecture》，参考：https://medP i c - X A Uium.n C f T +com/swlh/graphL C 4 R | | 2 aql-vs-rest-api-architecture-3b95a77512f5)

本文系本站编辑转载，文章版权归原作者所有，内容为作者个人观点，转载目的在于传递更多信息，并不代表本站赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请与本站联系，本站将在第一时间删除内容！

GraphQL与REST API架构