GraphQL vs. REST API

你有否參與過網頁應用程式開發項目？如果有，你可能已經遇到過 "GraphQL" 這個詞。但它究竟是什麼？它是用於伺服器端還是客戶端的配置？此外，什麼時候 GraphQL 集成比其他替代方案更可取？在本文中，我們將引導你解答這些問題。

作為在互聯網上軟件組件之間進行數據傳輸的通信通道，API 扮演著在現代網絡服務架構中不可或缺的角色，就像氧氣一樣。API 技術如 SOAP（網絡服務訊息協議）、REST（架構風格）、和 GraphQL（查詢語言和工具）透過支持不同服務之間的集成和數據交換來促進軟件開發，使開發變得更加便利和靈活。

儘管有許多類型的 API，近年來的辯論主要集中在兩個主要範式：REST（表述性狀態轉移）和 GraphQL。兩者都在全球網絡項目中提供一系列的優勢並被使用。然而，它們在如何管理數據通信方面有顯著的不同。

REST API 是什麼？#

REST 是一種於 21 世紀初期開發的結構化架構風格，用於構建跨網絡超媒體應用，旨在於客戶端和伺服器之間採用無狀態的、可緩存的通信協議。REST API（也稱為 RESTful API）是 REST 架構的驅動者。

REST API 使用統一資源標識符（URI）來尋址資源。REST API 使用不同的端點對網絡資源進行 CRUD（創建、讀取、更新和刪除）操作。它依賴於預定義的數據格式（稱為媒體類型或 MIME 類型）來決定它們提供給客戶端的資源的形式和大小。最常見的格式是 JSON 和 XML（有時是 HTML 或純文本）。

在客戶端請求資源後，伺服器處理查詢並返回與該資源相關的所有數據。響應包含 HTTP 響應代碼，如 "200 OK"（對於成功的 REST 請求）和 "404 Not Found"（對於不存在的資源）。

REST API 如何工作？#

REST API 依賴於預定義的端點，這些端點通過 HTTP 對資源進行公開。每個端點代表一個資源，例如用戶或帖子，並由一個唯一的 URL 識別。REST 操作與標準 HTTP 方法如 GET、POST、PUT 和 DELETE 綁定，這些分別對應於檢索、創建、更新和刪除數據。

例如，對 GET /users 的請求檢索用戶的完整列表，而 GET /users/123 則獲取由其 ID 識別的特定用戶的詳細信息。如果你還需要訪問相關數據，例如用戶的組織和組織角色，你將需要額外地呼叫 GET /users/123/organizations。

REST 遵循一個以資源為中心的方法，專注於訪問和操作離散的資源。

GraphQL 是什麼？#

GraphQL 既是一種 API 類型（或查詢語言），也是一個用於響應這些查詢的運行時引擎。它提供了一個簡化的 API，特別適合於需要特定數據子集的移動應用和複雜架構的實現。

使用 GraphQL，開發人員可以指定他們希望從 API 獲取的數據。它還允許按需檢索數據，而不是一次性提取所有數據，立即應用更改，並將第三方數據源整合到應用中。

應用可以使用 GraphQL 查詢調用 GraphQL 服務。這些查詢返回客戶端要求的精確數據元素。這樣可以節省多個 API 呼叫、網絡帶寬和後處理。這是一個位於消費設備附近的數據中心 API 的高效解決方案，例如平板電腦和手機。

GraphQL 如何工作？#

相反，GraphQL 採取一種基於查詢的方法。GraphQL 沒有預定義的端點，而是公開一個接受結構化查詢的單一端點。客戶端使用一種查詢語言來精確指定他們需要的數據。

因此，完整的 GraphQL 實現必須具備兩個部分：schema 和 resolvers。

GraphQL schema#

Schema 定義了可以通過 GraphQL 查詢檢索的數據類型及其字段：

例如，假設你有以下的 schema：

客戶端可以使用以下查詢來查詢用戶的名稱、郵箱、組織和角色：

此查詢不僅僅提取要求的字段（郵箱和組織），還在一次請求中檢索相關數據（角色）。

GraphQL resolver#

GraphQL resolver 是 GraphQL 伺服器中一個關鍵的組件，用於決定如何提取或計算客戶端在 GraphQL 查詢中請求的數據。當客戶端發送一個查詢時，每個查詢中的字段都匹配到一個 resolver，其中包含檢索或計算該字段數據的邏輯。

在上述例子中，schema 的 resolvers 如下所示：

有兩種類型的 resolvers：根 resolvers 和字段 resolvers。

• 根 Resolvers：處理 schema 中的頂層字段，例如 Query、Mutation 和 Subscription。
• 字段 Resolvers：處理類型中的單個字段，通常用於嵌套查詢。如果沒有為某個字段提供具體的 resolver，GraphQL 使用默認 resolver，這將從父對象返回具有匹配名稱的字段的值。

GraphQL 操作#

GraphQL 支持三種類型的操作：查詢、變更和訂閱。

• 查詢：用於讀取數據。
• 變更：用於寫入數據，包括添加、修改和刪除數據的操作。
• 訂閱：用於請求數據的持續連接，允許客戶端聲明其感興趣的事件類型和應返回的數據。

GraphQL 和 REST API 之間的差異#

GraphQL 和 REST API 是用於在不同的網絡服務之間交換數據的工具，但由於它們解決問題的方式不同，以下是它們之間的主要差異：

數據提取#

由於端點返回固定的響應，REST API 經常過度提取或不足提取數據。GraphQL 通過讓客戶端請求他們所需的精確數據，減少不必要的數據傳輸。這使 GraphQL 非常適合於數據需求複雜的應用，例如移動或低帶寬環境。

想像上述的例子，你需要提取用戶的靜態數據、用戶所屬的組織和組織中分配給用戶的角色。使用 REST API，你需要向不同的端點進行多次請求才能獲得所有數據。然而，使用 GraphQL，你可以在一次請求中獲取所有數據。

靈活性#

REST 的以端點為基礎的結構簡單明了，對於標準 CRUD 操作的簡單應用來說效果很好。這是因為 REST API 是為資源為中心設計的，每個端點都代表一個特定的資源。這種方法的主要限制在於它不允許快速的迭代和客戶端需求的更改。每次對客戶端進行更改時，伺服器必須通過添加新端點或更新已有端點來適應新的要求。這常常導致大量冗餘端點和複雜的 API 版本管理。

相對地，GraphQL 更加靈活，允許客戶端只請求他們所需的數據。這種靈活性在客戶端需求經常變化的情況下特別有用，因為它消除了修改伺服器端 API 實現的需求。客戶端可以請求新字段或嵌套數據，而不需要更改伺服器。

緩存#

即使 GraphQL 在數據提取方面更加高效和靈活，它也有一些缺點。其中一個主要問題是緩存。

REST API 擁有成熟的生態系統。由於其無狀態和標準化的特性，可以輕鬆地在伺服器和客戶端級別緩存響應。這可以顯著減少發送給伺服器的請求數量並提升性能。

然而，由於其靈活性，所以許多可用於 REST API 的緩存技術不適用於 GraphQL。這需要根據具體用例在客戶端處理緩存，這給客戶端開發帶來額外的工作量。

優劣#

結論#

雖然作為一個新手的 GraphQL 在近年來獲得了強勁的動力，但由於其原子設計和嚴謹，REST API 在相當一段時間內依然保持重要地位。

REST 和 GraphQL 服務於不同的需求並在不同的場景中表現優異。REST 的簡單性使其成為簡單應用和微服務的完美選擇。在需要靈活和高效的數據檢索的場景，特別是在擁有多樣化客戶端或數據關係複雜的應用中，GraphQL 突顯出色。兩者之間的選擇取決於你的項目的具體要求、團隊專業知識和長期可擴展性需求。