GraphQL 和 REST 对比时需要注意些什么

在法国巴黎 API 日这上，Arnaud Lauret 谈了 GraphQL 和 RESTful HTTP API 各自的优点和缺点。从他的总结可以看出，是使用场景决定了具体该使用哪种 API，而且这两类 API 在实际使用中会有很多的权衡考虑。

GraphQL 是一种 API 查询语言，是由 Facebook 创建并最终开源的，可以认为是 REST 的一种替代品。来自 AXA Banque 的 API 架构师 Lauret 给出了一些可对二者进行比较的切入点：

• GraphQL 能够通过一次查询得到所有需要的数据，从而减少网络跳转的次数。
• GraphQL 采用所见即所得模型，这样客户端代码不易出错。
• RESTful HTTP 通过使用状态码和 HTTP verb，提高了结果的一致性和可预测性。
• 借助超媒体，在用户使用 API 时可以“发现”资源间的关系，这简化了 RESTful 用户的具体实现。
• HTTP 实现了缓存机制而 GraphQL 还没有实现。
• GraphQL 给用户提供了 schema，这很有用，但是需要注意的是接口描述并非 API 文档。

Lauret 认为 GraphQL 的主要优势是其使用的所见即所得 (WYSIWYG) 模型。也就是说，查询结果的结构是查询结构本身的精确映射，这样的话，用户在解排（unmarshal）响应的时候不容易出错。

他也解释了为什么 GraphQL 模型可以减少网络跳转次数。对 RESTful HTTP 来说，资源和子资源可能存在于不同的节点上，所以需要多个请求才能获取到期望的数据的情况就在所难免。但是 GraphQL 却可以在单次请求中获取到所有期望数据。实际上，一次只查询系统中的一种资源是有可能的。

虽然 Lauret 认为模型非常强大，但是他也解释了单端点方案可能带来的一致性和可预测性损失。相对于 RESTful HTTP API，GraphQL 不能正确使用 HTTP verb 会带来很明显的损失。举个例子，在使用 RESTful HTTP 时，当用户向资源发送了 DELETE 请求时，用户清楚这个操作是安全和幂等的，同时也清楚这个操作是用来删除资源的。

Lauret 指出 GraphQL 缺少 HTTP 状态码会带来可预测性损失，HTTP 状态码是人机都可读的。相关的例子如当不能找到资源时返回的 404 状态码，或者用户没有权限访问时返回 403 状态码等等。

REST 充分利用了超媒体，也就是说通过遍历 API，用户就可以发现链接和相关资源。这就消除了用户用于链接构建和给客户端返回资源关系等操作的需求。Lauret 解释说因为 GraphQL 完全聚焦于数据，所以开发者会更加依赖于文档。

因为 HTTP 缓存已经是 web 架构的一部分，所以 Laure 强调 HTTP RESTful API 使用了这种标准的 HTTP 缓存，而 GraphQL 的用户则需要自己实现缓存机制, 这种额外的负担其实是可以避免的。

Lauret 列出了 GraphQL 的最后一个优势，即提供 schema，schema 可以在运行时被获取到。当客户端决定可能的查询时，这非常有用。但是 Lauret 警告说接口描述不是文档，GraphQL 不足以解决所有的 API 文档问题。

作为总结，Lauret 认为没有通用方案，只要是对当前需求有利的方案都可以使用。他也提到，由于高级 API 所具有的共性，如果用户不善于使用某种 API，那么他们其实不善于使用任何一种 API。完整视频可以通过这里在线观看，关于该演讲的总结可以参考该篇博客文章。

查看英文原文： GraphQL vs REST: Things to Consider

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。