[译] 怎样使用GraphQL - 2.GraphQL是更好的REST

英文原版地址：https://www.howtographql.com/...

在过去十年中，REST已经成为设计Web API的标准。它提供了一些伟大的想法，如无状态服务和结构化资源访问。然而，基于REST的API太死板，不能满足客户端快速变化的调用需求。

GraphQL的出现是为了应对更多的灵活性和效率的需要！它解决了与REST API打交道时，开发人员遇到的许多REST的缺点和低效性。

为了说明REST和GraphQL在从API获取数据时的主要区别，我们来考虑一个简单的示例场景：在博客应用中，应用需要展示指定用户的帖子标题。同一页面里还会显示该用户的最新3个关注者的名字。 REST和GraphQL是如何解决这个业务的呢？

REST vs GraphQL之数据获取

使用REST API时，通常可以调用多个接口来获取数据。针对上述场景，首先可以调用/user/<id>接口来获取用户数据。紧接着，调用/users/<id>/posts返回该用户的所有帖子。最后，第三个接口可以是/users/<id>/followers，返回该用户的关注者列表。

使用REST，必须向三个不同的接口发出三个请求以获取所需的数据。同时你也拿到了额外的数据，因为接口会返回你不需要的其他信息。

另一方面，在GraphQL中，你只需向拥有数据的GraphQL服务端发送一条查询语句。服务端就会响应并返回带有查询结果的JSON对象。

使用GraphQL，客户端可以精确地指定查询中需要的数据。 请注意，服务器响应的结构会精确地匹配查询中定义的结构。

不再获取多余或不足的数据

REST最常见的缺点之一是不能精准的获取数据。这是因为客户端获取数据的唯一方法是调用接口，而接口总是返回固定数据结构。如果想设计出完美的API，刚好能为客户端提供精确的数据，是非常困难的。

“用图形的方式思考，而不是端点”。GraphQL共同发明人Lee Byron的Lessons From 4 Years of GraphQL。

过多获取：下载了多余的数据

过多获取，意味着客户端拿到了超出真正需要额外的数据。想象一下，在一个页面中，只需要展示一组用户名称列表。但在REST API中，通常会调用/users接口，来获取包含用户数据在内的JSON数组。然而，这个返回结果中可能也包含了用户的其他信息，例如。用户的生日，地址等。而我们仅仅是想展示用户名。

获取不足和n+1问题

另外一个问题是获取的数据不足，然后多发一次请求的问题。获取不足通常是指接口不能返回所需信息。客户端将不得不再次发起请求来获取数据。可能的场景是，客户端需要先得到列表数据，然后为列表中的每个元素再次发起请求来获取元素相关数据。

例如，假设刚才的应用中，需要展示出每个用户的最后三个关注者。 API也提供了接口/users/<user-id>/followers。为了能够展示所需的信息，应用需要向/users接口发起请求，然后针对每个用户再去调用/users/<user-id>/followers接口。

前端的快速产品迭代

使用REST API的常见模式是，根据应用页面的需要来设计接口。这样做很便捷，只要简单地在客户端调用对应接口，就能获取页面中所有需要的数据。

但是这种模式最主要的缺点是，不允许在前端快速迭代。随着UI层面的每一个改动，接口数据是否匹配，这一点就暴露了很高的风险。因此，后端就需要进行调整，以解决新的数据需求。这会导致生产力下降，特别是降低了将用户建议快速整合进产品的能力。

如果使用GraphQL，这个问题迎刃而解。得益于GraphQL的灵活性，客户端的更改不需要服务端有任何额外的工作。客户端可以指定其确切的数据要求，因此前端的设计和数据方面的需求变化时，后端工程师不需要进行调整。

后端深度分析

GraphQL可以对请求的数据进行细粒度的分析。由于每个客户端都准确地指定了它感兴趣的数据，因此，我们可以深入了解关于数据的使用方式。有了这些信息，就可以用来优化API，和去除不需要的字段。

使用GraphQL，还可以对服务器处理请求时，进行低级别的性能监控。 GraphQL使用resolver函数的概念来收集客户端请求的数据。通过resolver提供的测量和性能数据，可以为解决系统中的瓶颈问题提供重要的见解。

Schema和类型系统的好处

GraphQL使用丰富的类型系统来定义API的功能。 API中暴露的所有类型都使用GraphQL模式定义语言（SDL）在Schema中记录下来。Schema是客户端和服务端之间的协定，以定义客户端如何访问数据。

一旦定义了Schema，在前端和后端工作的团队可以在不进行多余沟通的情况下开展工作，因为他们都知道经由网络传输的数据的确定结构。

前端工程师可以通过mock所需的数据结构轻松的进行测试。一旦服务端准备就绪，客户端可以快速切换到真正的服务，接着从真正的API加载数据。