GraphQL vs REST：API實現哪家強？

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

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

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

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

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

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

• 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。完整視頻可以通過這裡在線觀看：

關於該演講的總結可以參考該篇博客文章：