GitHub 采用了新的 GraphQL API

近期在 GitHub 全球大会上，GitHub 推出了新 API 的 alpha 预览版，该版 API 使用 Facebook 的 GraphQL （一种允许自服务 API 契约的查询语言）编写。GitHub 在其工程博客写道，GitHub 对API 范式的转换主要是因为现有的RESTful 契约缺乏可扩展性。为迎合大量各异客户的需求，REST 不能在提供GitHub 所需灵活性的同时维持较低的维护代价。

GitHub 将现有 API 迁移到 GraphQL 的公告，与数日后 Facebook 将最终移除其服务的“技术预览”绰号的决定是遥相呼应的。虽然早自2002 年起，GraphQL 就已用于Facebook 的生产环境中，但由于直至最近GraphQL 的九月中期版本才得以开源，所以其在技术上依然是一个“预览版”。总体而言，社区对GraphQL 表现出复杂的反应，一些人宣称 GraphQL 给服务器端代码带来了不公平的额外复杂度和管理，也有一些人对 GraphQL 分隔各种个体消费者的数据消费需求和核心数据本身的能力青睐有加，认为这将使API 更具可扩展性和多样性。GitHub 在其工程博客上这样地描述当前的API：“不管我们提供了多少信息，来自集成商那里的反馈依然认为我们的REST API 还不够灵活。有时为构成对一个资源的完整视图，需要做两次或三次单独调用。看上去尽管我们的响应同时发送了太多的数据，但是其中并未包括用户所需的数据。”这里Github 暗示GraphQL 非常适合于具有大量各异客户的应用场景，其中客户对底层数据具有复杂规模的需求。而对于为一个并没有多少开发人员消费的简单网站提供API，GraphQL 并不能体现出其相对于REST 的优越性。

在其工程博客中，GitHub 指出其API 的历史开始于2008 年。其中提及Github 的第一个RESTful API 成为了很多企业的样板，彼时这些企业正为精雕细琢其自身的REST API 而寻找实例模板。GitHub 希望GraphQL 能像其首次涉足REST 时那样，为那些寻求很好的方式去从多消费者复杂数据需求中受益的开发人员和企业树立样板。正如在GraphQL 技术预览版发布后的InfoQ 文章中，GraphSQL 的早期贡献者之一Lee Byron所说的：“社区不仅在使用GraphQL，同时也在创建它。”作为GraphQL 的首批主流用户之一，GitHub 自采用GraphQL 以来就一直在转变它。在GitHub 上，GraphQL 已从其早期的JavaScript 构建，转变为使用从Java 到C#和Ruby（Ruby 是GitHub 自身也在使用的）等多种语言构建，现在平台上已有种类繁多的开源工具。

虽然看上去GitHub 转到GraphQL 的主要原因是为了实现适合各种客户所需的可扩展性，但是GitHub 也提及很多额外的优点。在其技术博客中这样写道：“GraphQL 代表了API 开发中的一个巨大飞跃。类型安全、内省、文档生成和可预测响应，这使我们平台的维护者和客户均可从中受益。”考虑到GitHub 当前所呈现出的数据规模，文档生成和内省有益于数据的消费。此外， Swagger 等工具非常有助于 RESTful API 的文档化，GitHub 确需贯穿整个代码库的手工注解创建，这些注解易于变成和代码注释一样的陈旧。GitHub 可以使用 GraphQL 所包括的所有工具，与相应的 API 改变和必要的 API 文档一起发布其中的软件，这对于 GitHub 及其用户而言均为一个重大利好。

查看英文原文： GitHub Adopts New GraphQL API

感谢夏雪对本文的审校。

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