近期在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