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

Github将现有API迁移到GraphQL的公告，与数日后Fackbook将最终移除其服务的“技术预览”绰号的决定是遥相呼应的。虽然早自2002年起，GraphQL就已用于Fackbook的生产环境中，但由于直至最近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自身也在使用的）等多种语言构建，现在平台上已有种类繁多的开源工具。

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

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