[译] 怎样使用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加载数据。