探索 GraphQL 和 REST API 的主要差異、它們的優勢，以及在何時使用它們以達至最佳的網絡開發效果。
你有否參與過網頁應用程式開發項目？如果有，你可能已經遇到過 "GraphQL" 這個詞。但它究竟是什麼？它是用於伺服器端還是客戶端的配置？此外，什麼時候 GraphQL 集成比其他替代方案更可取？在本文中，我們將引導你解答這些問題。
作為在互聯網上軟件組件之間進行數據傳輸的通信通道，API 扮演著在現代網絡服務架構中不可或缺的角色，就像氧氣一樣。API 技術如 SOAP（網絡服務訊息協議）、REST（架構風格）、和 GraphQL（查詢語言和工具）透過支持不同服務之間的集成和數據交換來促進軟件開發，使開發變得更加便利和靈活。
儘管有許多類型的 API，近年來的辯論主要集中在兩個主要範式：REST（表述性狀態轉移）和 GraphQL。兩者都在全球網絡項目中提供一系列的優勢並被使用。然而，它們在如何管理數據通信方面有顯著的不同。
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 依賴於預定義的端點，這些端點通過 HTTP 對資源進行公開。每個端點代表一個資源，例如用戶或帖子，並由一個唯一的 URL 識別。REST 操作與標準 HTTP 方法如 GET、POST、PUT 和 DELETE 綁定，這些分別對應於檢索、創建、更新和刪除數據。
例如，對 GET /users 的請求檢索用戶的完整列表，而 GET /users/123 則獲取由其 ID 識別的特定用戶的詳細信息。如果你還需要訪問相關數據，例如用戶的組織和組織角色，你將需要額外地呼叫 GET /users/123/organizations。
REST 遵循一個以資源為中心的方法，專注於訪問和操作離散的資源。
GraphQL 既是一種 API 類型（或查詢語言），也是一個用於響應這些查詢的運行時引擎。它提供了一個簡化的 API，特別適合於需要特定數據子集的移動應用和複雜架構的實現。
使用 GraphQL，開發人員可以指定他們希望從 API 獲取的數據。它還允許按需檢索數據，而不是一次性提取所有數據，立即應用更改，並將第三方數據源整合到應用中。
應用可以使用 GraphQL 查詢調用 GraphQL 服務。這些查詢返回客戶端要求的精確數據元素。這樣可以節省多個 API 呼叫、網絡帶寬和後處理。這是一個位於消費設備附近的數據中心 API 的高效解決方案，例如平板電腦和手機。
相反，GraphQL 採取一種基於查詢的方法。GraphQL 沒有預定義的端點，而是公開一個接受結構化查詢的單一端點。客戶端使用一種查詢語言來精確指定他們需要的數據。
因此，完整的 GraphQL 實現必須具備兩個部分：schema 和 resolvers。
Schema 定義了可以通過 GraphQL 查詢檢索的數據類型及其字段：
例如，假設你有以下的 schema：
客戶端可以使用以下查詢來查詢用戶的名稱、郵箱、組織和角色：
此查詢不僅僅提取要求的字段（郵箱和組織），還在一次請求中檢索相關數據（角色）。
GraphQL resolver 是 GraphQL 伺服器中一個關鍵的組件，用於決定如何提取或計算客戶端在 GraphQL 查詢中請求的數據。當客戶端發送一個查詢時，每個查詢中的字段都匹配到一個 resolver，其中包含檢索或計算該字段數據的邏輯。
在上述例子中，schema 的 resolvers 如下所示：
有兩種類型的 resolvers：根 resolvers 和字段 resolvers。
GraphQL 支持三種類型的操作：查詢、變更和訂閱。
查詢：用於讀取數據。變更：用於寫入數據，包括添加、修改和刪除數據的操作。訂閱：用於請求數據的持續連接，允許客戶端聲明其感興趣的事件類型和應返回的數據。GraphQL 和 REST API 是用於在不同的網絡服務之間交換數據的工具，但由於它們解決問題的方式不同，以下是它們之間的主要差異：
由於端點返回固定的響應，REST API 經常過度提取或不足提取數據。GraphQL 通過讓客戶端請求他們所需的精確數據，減少不必要的數據傳輸。這使 GraphQL 非常適合於數據需求複雜的應用，例如移動或低帶寬環境。
想像上述的例子，你需要提取用戶的靜態數據、用戶所屬的組織和組織中分配給用戶的角色。使用 REST API，你需要向不同的端點進行多次請求才能獲得所有數據。然而，使用 GraphQL，你可以在一次請求中獲取所有數據。
REST 的以端點為基礎的結構簡單明了，對於標準 CRUD 操作的簡單應用來說效果很好。這是因為 REST API 是為資源為中心設計的，每個端點都代表一個特定的資源。這種方法的主要限制在於它不允許快速的迭代和客戶端需求的更改。每次對客戶端進行更改時，伺服器必須通過添加新端點或更新已有端點來適應新的要求。這常常導致大量冗餘端點和複雜的 API 版本管理。
相對地，GraphQL 更加靈活，允許客戶端只請求他們所需的數據。這種靈活性在客戶端需求經常變化的情況下特別有用，因為它消除了修改伺服器端 API 實現的需求。客戶端可以請求新字段或嵌套數據，而不需要更改伺服器。
即使 GraphQL 在數據提取方面更加高效和靈活，它也有一些缺點。其中一個主要問題是緩存。
REST API 擁有成熟的生態系統。由於其無狀態和標準化的特性，可以輕鬆地在伺服器和客戶端級別緩存響應。這可以顯著減少發送給伺服器的請求數量並提升性能。
然而，由於其靈活性，所以許多可用於 REST API 的緩存技術不適用於 GraphQL。這需要根據具體用例在客戶端處理緩存，這給客戶端開發帶來額外的工作量。
| 名稱 | 優點 | 缺點 |
|---|---|---|
| REST API | - 簡單且廣泛採用，擁有豐富的工具和社區支持。 - 結構清晰，方便初學者理解。 - 內置使用 HTTP 標準的緩存支持。 | - 過度提取或不足提取數據 - 更改通常需創建新版本，增加維護成本。 |
| GraphQL | - 精確的數據提取提升了性能和效率。 - Schema 進化降低了版本控制的需求。 - 強大的工具，如內省和類型檢查，提升了開發體驗。 | - 與 REST 相比，設置和學習曲線更加複雜。 - 因不依賴於 HTTP 緩存，需要自定義的緩存解決方案。 - 單一端點設計可能複雜化調試和監控。 |
雖然作為一個新手的 GraphQL 在近年來獲得了強勁的動力，但由於其原子設計和嚴謹，REST API 在相當一段時間內依然保持重要地位。
REST 和 GraphQL 服務於不同的需求並在不同的場景中表現優異。REST 的簡單性使其成為簡單應用和微服務的完美選擇。在需要靈活和高效的數據檢索的場景，特別是在擁有多樣化客戶端或數據關係複雜的應用中，GraphQL 突顯出色。兩者之間的選擇取決於你的項目的具體要求、團隊專業知識和長期可擴展性需求。