近期在Github全球大會上，Github推出了新API的alpha預(yù)覽版，該版API使用Fackbook的GraphQL（一種允許自服務(wù)API契約的查詢語言）編寫。Github在其工程博客寫道，Github對API范式的轉(zhuǎn)換主要是因為現(xiàn)有的RESTful契約缺乏可擴展性。為迎合大量各異客戶的需求，REST不能在提供GitHub所需靈活性的同時維持較低的維護代價。

Github將現(xiàn)有API遷移到GraphQL的公告，與數(shù)日后Fackbook將最終移除其服務(wù)的“技術(shù)預(yù)覽”綽號的決定是遙相呼應(yīng)的。雖然早自2002年起，GraphQL就已用于Fackbook的生產(chǎn)環(huán)境中，但由于直至最近GraphQL的九月中期版本才得以開源，所以其在技術(shù)上依然是一個“預(yù)覽版”。總體而言，社區(qū)對GraphQL表現(xiàn)出復(fù)雜的反應(yīng)，一些人宣稱GraphQL給服務(wù)器端代碼帶來了不公平的額外復(fù)雜度和管理，也有一些人對GraphQL分隔各種個體消費者的數(shù)據(jù)消費需求和核心數(shù)據(jù)本身的能力青睞有加，認為這將使API更具可擴展性和多樣性。Github在其工程博客上這樣地描述當(dāng)前的API：“不管我們提供了多少信息，來自集成商那里的反饋依然認為我們的REST API還不夠靈活。有時為構(gòu)成對一個資源的完整視圖，需要做兩次或三次單獨調(diào)用。看上去盡管我們的響應(yīng)同時發(fā)送了太多的數(shù)據(jù)，但是其中并未包括用戶所需的數(shù)據(jù)。”這里Github暗示GraphQL非常適合于具有大量各異客戶的應(yīng)用場景，其中客戶對底層數(shù)據(jù)具有復(fù)雜規(guī)模的需求。而對于為一個并沒有多少開發(fā)人員消費的簡單網(wǎng)站提供API，GraphQL并不能體現(xiàn)出其相對于REST的優(yōu)越性。

在其工程博客中，Github指出其API的歷史開始于2008年。其中提及Github的第一個RESTful API成為了很多企業(yè)的樣板，彼時這些企業(yè)正為精雕細琢其自身的REST API而尋找實例模板。Github希望GraphQL能像其首次涉足REST時那樣，為那些尋求很好的方式去從多消費者復(fù)雜數(shù)據(jù)需求中受益的開發(fā)人員和企業(yè)樹立樣板。正如在GraphQL技術(shù)預(yù)覽版發(fā)布后的InfoQ文章中，GraphSQL的早期貢獻者之一Lee Byron所說的：“社區(qū)不僅在使用GraphQL，同時也在創(chuàng)建它。”作為GraphQL的首批主流用戶之一，Github自采用GraphQL以來就一直在轉(zhuǎn)變它。在Github上，GraphQL已從其早期的Javascript構(gòu)建，轉(zhuǎn)變?yōu)槭褂脧腏ava到C#和Ruby（Ruby是Github自身也在使用的）等多種語言構(gòu)建，現(xiàn)在平臺上已有種類繁多的開源工具。

雖然看上去Githb轉(zhuǎn)到GraphQL的主要原因是為了實現(xiàn)適合各種客戶所需的可擴展性，但是Github也提及很多額外的優(yōu)點。在其技術(shù)博客中這樣寫道：“GraphQL代表了API開發(fā)中的一個巨大飛躍。類型安全、內(nèi)省、文檔生成和可預(yù)測響應(yīng)，這使我們平臺的維護者和客戶均可從中受益。”考慮到Github當(dāng)前所呈現(xiàn)出的數(shù)據(jù)規(guī)模，文檔生成和內(nèi)省有益于數(shù)據(jù)的消費。此外，Swagger等工具非常有助于RESTful API的文檔化，Github確需貫穿整個代碼庫的手工注解創(chuàng)建，這些注解易于變成和代碼注釋一樣的陳舊。Github可以使用GraphQL所包括的所有工具，與相應(yīng)的API改變和必要的API文檔一起發(fā)布其中的軟件，這對于Github及其用戶而言均為一個重大利好。

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