原文链接： GraphQL vs. REST: What’s The Advantage?

由 Facebook 开创的 GraphQL，自 2015 年面世以来就一直在改进着 web 和原生应用。相比较于传统的 REST API，它的几个优势也使得其使用率迅速提升。

优势 1：更少的数据

大多数你消费的目标数据来源于某个地方的数据库。如果你正好在 SQL 数据库上工作，你应该知道，只请求你所需要的字段比请求所有的字段要更高效。

在 REST 的体系中，几乎不可能只指定你需要的字段。结果，你通常会获取比你所需要的更多的数据。如果你需要一次获得多条记录，这时你就需要处理一个指数级的问题。

在 Manifold，我们与所有 REST 终端返回的数据做斗争。

REST

1	https://api.catalog.manifold.co/v1/products

这个链接返回 141 KB 的 JSON 数据，并且这还不是我们最重的终端。（我们最重的 REST 终端返回 1M 以上的 JSON 数据！）对于这个终端，任何时候我们需要任意产品的数据的时候，这份数据都会装载到客户端里。并且，在 REST 工作的方式中，这只是我们需要渲染一个页面所需的几个调用中的一个。

相比于我们的 GraphQL 终端：

//request
{
  products(first: 100) {
    edgets {
      node {
        displayName
        logoUrl
        tagline
      }
    }
  }
}

//response
{
  "data": {
    "products": {
      "edges": [
        {
          "node": {
            "displayName": "Dumper",
            "logoUrl": "https://cdn.manifold.co/providers/dumper/logos/512x512_2.png",
            "tagline": "Off-site backup-as-a-service for MySQL, PostgreSQL, MongoDB and Redis."
          }
        },
        {
          "node": {
            "displayName": "Blitline",
            "logoUrl": "https://cdn.manifold.co/providers/blitline/logos/blitline.png",
            "tagline": "Premium image processing and rasterization API for enterprise systems"
          }
        },
        ...
      ]
    }
  }
}

如果我们只需要三个字段，我们的 GraphQL 终端只返回我们所需要的，并且只有 9.4 KB，比 REST 要小 95%。

此外，很多时候我们需要通过后续的 REST 请求来获取一个产品的计划数据（我们将在接下来谈到链式）。对于我们查询的每个产品，我们有时候也需要查询它的计划。这是一个示例，关于如何将这些多重查询结合成一个 GraphQL 查询（以及一些其他用于比较的场景）：

场景	REST 数据量	GraphQL 数据量	降低
所有产品 + 所有计划	`562.4 KB`	`15.4 KB`	97%
所有产品	`141 KB`	`9.4 KB`	95%
单个产品	`4.1 KB`	`0.2 KB`	95%

并且思考一下：这节约的只是针对一个用户的。想象一下大规模应用后它将带来什么：技能降低加载时间，又能降低带宽占用。

优势 2：组合请求

GraphQL 另外一个重要的优势即是其组合多个请求的能力。如果你之前使用过 REST，你可能常常经历链式调用的痛苦：

我们需要展示一个团队，先来调用 /team/:id 请求。
每个 team 拥有一系列的 userIDs。对于每个团队用户，我们需要调用 /user/:id 请求对于每个这些 ID。
我们还想要展示有哪些其他的队伍上也包含了这个 user。此时我们针对每个团队、每个用户再次调用 /team/:id。

让我们把它加起来：

1
2
3

/team/:id  1
/user/:id  n (n: 团队里成员的数量)
/team/:id  n × t (t: 每个用户的团队数量)

如果这是一个拥有 20 个用户的团队