GraphQL和REST對比時需要注意些什麼

在法國巴黎API日這上，Arnaud Lauret談了GraphQL和RESTful HTTP API各自的優點和缺點。從他的總結可以看出，是使用場景決定了具體該使用哪種API，而且這兩類API在實際使用中會有很多的權衡考慮。

GraphQL是一種API查詢語言，是由Facebook創建並最終開源的，可以認為是REST的一種替代品。來自AXA Banque的API架構師Lauret給出了一些可對二者進行比較的切入點：

GraphQL能夠通過一次查詢得到所有需要的數據，從而減少網路跳轉的次數。

GraphQL採用所見即所得模型，這樣客戶端代碼不易出錯。

RESTful HTTP通過使用狀態碼和HTTP verb，提高了結果的一致性和可預測性。

藉助超媒體，在用戶使用API時可以「發現」資源間的關係，這簡化了RESTful用戶的具體實現。

HTTP實現了緩存機制而GraphQL還沒有實現。

GraphQL給用戶提供了schema，這很有用，但是需要注意的是介面描述並非API文檔。

Lauret認為GraphQL的主要優勢是其使用的所見即所得(WYSIWYG)模型。也就是說，查詢結果的結構是查詢結構本身的精確映射，這樣的話，用戶在解排（unmarshal）響應的時候不容易出錯。

他也解釋了為什麼GraphQL模型可以減少網路跳轉次數。對RESTful HTTP來說，資源和子資源可能存在於不同的節點上，所以需要多個請求才能獲取到期望的數據的情況就在所難免。但是GraphQL卻可以在單次請求中獲取到所有期望數據。實際上，一次只查詢系統中的一種資源是有可能的。

雖然Lauret認為模型非常強大，但是他也解釋了單端點方案可能帶來的一致性和可預測性損失。相對於RESTful HTTP API，GraphQL不能正確使用HTTP verb會帶來很明顯的損失。舉個例子，在使用RESTful HTTP時，當用戶向資源發送了DELETE請求時，用戶清楚這個操作是安全和冪等的，同時也清楚這個操作是用來刪除資源的。

Lauret指出GraphQL缺少HTTP狀態碼會帶來可預測性損失，HTTP狀態碼是人機都可讀的。相關的例子如當不能找到資源時返回的404狀態碼，或者用戶沒有許可權訪問時返回403狀態碼等等。

REST充分利用了超媒體，也就是說通過遍歷API，用戶就可以發現鏈接和相關資源。這就消除了用戶用於鏈接構建和給客戶端返回資源關係等操作的需求。Lauret解釋說因為GraphQL完全聚焦於數據，所以開發者會更加依賴於文檔。

因為HTTP緩存已經是web架構的一部分，所以Laure強調HTTP RESTful API使用了這種標準的HTTP緩存，而GraphQL的用戶則需要自己實現緩存機制, 這種額外的負擔其實是可以避免的。

Lauret列出了GraphQL的最後一個優勢，即提供schema，schema可以在運行時被獲取到。當客戶端決定可能的查詢時，這非常有用。但是Lauret警告說介面描述不是文檔，GraphQL不足以解決所有的API文檔問題。

作為總結，Lauret認為沒有通用方案，只要是對當前需求有利的方案都可以使用。他也提到，由於高級API所具有的共性，如果用戶不善於使用某種API，那麼他們其實不善於使用任何一種API。完整視頻可以通過這裡在線觀看，關於該演講的總結可以參考該篇博客文章。

查看英文原文：GraphQL vs REST: Things to Consider

感謝張衛濱對本文的審校。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！