【51CTO.com快譯】GraphQL服務端向客戶端提供了一種預定義式的架構。它支持從服務端檢索某種模型的數據。其結構模式充當了服務端和客戶端之間的連接器，同時也定義了訪問信息的過程。

GraphQL架構的各種基本元素，都是以SDL(Schema Definition Language，模式定義語言)記錄下來的。這些記錄解釋了哪些對象可以在特定的服務端被請求，它們擁有哪些字段，允許請求獲取哪些類型的數據，以及這些類型之間的關系。

為了確保服務端能夠響應某種查詢，并保證客戶端可以根據既定的模式來驗證該查詢，您可以開發(fā)出特有的GraphQL模式，并使用任何一種編程語言來創(chuàng)建對應的接口。籍此，您便可以根據與結果相匹配的GraphQL查詢格式，來預測對應的結果。此外，GraphQL模式還能夠避免出現(xiàn)諸如結構錯誤或數據不可用，等異常情況。

可見，只有在GraphQL的相關操作到達后端應用之后，針對完整架構的解析才能進行，而前端應用的數據也才能被準確地解析出來。

GraphQL操作

目前，GraphQL具有如下三種主要操作方式：

• 查詢讀取數據
• 寫入數據的變化
• 隨著時間的推移，自動接收實時數據

GraphQL將全量數據集的方式改進為：僅在同一個請求中就實現(xiàn)數據的查詢與接受。這種客戶端驅動式(client-driven)的方法備受開發(fā)人員的推崇。至于返回的數據類型，GraphQL將此類數據控制權交付給了客戶端。

而對于REST而言，由于服務端預先定義好了所有資源的可用數據。因此就算只需要一部分數據，客戶端也必須通過重復的網絡請求，來獲取資源中的全量信息。這就產生了所謂的過度獲取(over-fetching)的問題。

GraphQL與REST的優(yōu)勢相比

GraphQL和REST都是構建和使用API​​所需的規(guī)范。這兩種技術的共同特點是：在通過發(fā)送查詢請求來檢索資源時，它們都可以在請求中返回JSON數據。

此外，它們都可以通過HTTP的方式進行操作。而由于它們都充當了調用服務端函數的數據入口，因此REST和GraphQL的端點字段有著許多相似之處。

雖然有著上述共同點，但是它們的概念模型卻有著明顯的差異。GraphQL建立在圖形基礎上的;而REST則建立在文件之上。這就導致了開發(fā)人員在構建和使用API​​上會產生不同的體驗。

就運行速度而言，GrapgQL更快。用戶可以通過選擇需要在其上運行的查詢字段數量，來減少請求以及實際消耗的時間。這便是GraphQL API比REST API更受歡迎的原因之一。此外還有：

1)是多面(Multifaceted)系統(tǒng)和微服務的絕配

GraphQL可以通過在API后端集成多個系統(tǒng)，來統(tǒng)一和隱藏實現(xiàn)的復雜性。GraphQL的服務端負責從當前的系統(tǒng)中獲取數據，然后將其打包成為GraphQL的響應格式。這對于多年來一直需要通過大量擴展第三方API的舊版架構來說，是尤為重要的。同時，GraphQL也減少了不少的維護負擔。

通過將單體的后端應用遷移到微服務的架構之中，我們可以把多個微服務合并到GraphQL的模式里，以實現(xiàn)它們之間的通信。此外，即使每一個微服務都定義了自己的GraphQL模式，并具有自己的GraphQL端點，我們也可以通過某一個GraphQL API網關，來將其整合為全局模式。

2)通過單個API的調用來獲取信息

由于REST分散在各個端點處，因此開發(fā)人員往往需要合并多個端點，來收集所有需要的數據。而對于專注于主要任務的GraphQL而言，開發(fā)人員僅需一個API調用，便可以請求到各種所需的信息。

3)恰當獲取數據

以REST方式獲取響應數據有一個不穩(wěn)定的因素：數據要么太少要么過多，因此，開發(fā)人員不得不執(zhí)行多個查詢請求。而由于GraphQL能夠通過單個請求，獲取確切的數據，因此它有效地解決了此類問題。

4)按需調整請求

通常，開發(fā)人員只能通過REST API文檔，來請求特定端點的相關功能與參數。而GraphQL能夠描述數據的類型、字段以及它們之間的交互點。因此GraphQL開發(fā)人員可以自定義請求，并訪問各種必要的信息。

5)開箱即用的身份驗證和類型檢查

GraphQL的自省(introspection)功能使得用戶可以檢測類型、并查找模式，進而確保應用程序只采用正確的結構，去請求所需的內容。

此外，開發(fā)人員還可以借助GraphQL IDE，將新的字段添加到當前的查詢之中，而無需額外地驗證數據格式。他們需要做的只是編寫解析器。

6)自動生成API文檔

由于文檔與代碼緊密相關，因此GraphQL API的變更能夠保持同步。一旦有某個字段、查詢或類型發(fā)生了改變，其對應的文檔將自動觸發(fā)修改。

7)API的迭代不產生新版本

作為一款不斷迭代的API，REST提供了多個不同的API版本。這就意味著：開發(fā)人員必須保留舊的版本，直至遷移到新的版本上。

而GraphQL則可以從架構中直接刪除“老化”的字段，而不會影響到將來對于現(xiàn)有方式的查詢。此舉確保了GraphQL在不斷迭代的過程中，仍然可以不間斷地訪問到目標應用的新功能，同時也能夠保持服務端代碼的整潔與易維護性。

8)代碼共享

如果需要代碼重用，那些在GraphQL多個查詢中所用到的字段，可以實現(xiàn)高級別的組件共享。這些代碼段可以讓用戶在保持相同的架構字段的基礎上，訪問到各種類型的數據。

9)詳細的錯誤消息

為了能夠準確地定位到程序中出現(xiàn)的問題，以及對應的解決方案，REST需要通過檢查HTTP頭，來獲取響應狀態(tài)。而在GraphQL中，如果處理過程發(fā)生了錯誤，則后端會提供包含有解析程序的詳細消息，以準確定位查詢失敗的確切部分。

10)權限

相較于REST的簡單視圖，開發(fā)人員可以在創(chuàng)建GraphQL模式時，選擇需要全面展示的功能，及其具體的工作方式。因此，用戶能夠根據具體情況，細粒度地顯示不同程度的視圖。

總結

我們不能武斷地認為：作為工具的GraphQL將可以完全替代作為架構模式的REST。到底哪一個更合適您手頭的項目，還是取決于特定的API交互模式，以及具體的使用場景。

原文標題：GraphQL: The Future of APIs，作者：Noa James

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】