繁體中文（台灣）
GraphQL 與 REST API
探索 GraphQL 與 REST API 之間的主要差異、它們的優勢，以及在何時使用每種 API 以達到最佳的 Web 開發效果。
Darcy Ye
Developer
Developer
Simeng
Developer
Developer
探索 GraphQL 與 REST API 之間的主要差異、它們的優勢，以及在何時使用每種 API 以達到最佳的 Web 開發效果。
你曾經參與過網頁應用程式開發專案嗎？如果有，那麼你可能已經聽過 "GraphQL" 這個詞。但它到底是什麼呢？是用於伺服器端還是用於客戶端設定？此外，什麼情況下 GraphQL 整合比其他選項更好？在這篇文章中，我們將引導你回答這些問題。
作為網際網路上軟體組件之間進行數據傳輸的通信渠道，API 在現代網路服務架構中扮演著不可或缺的角色，如同氧氣一樣。SOAP（一種網路服務訊息協定）、REST（架構風格）和 GraphQL（一種查詢語言與工具）等 API 技術通過支持不同服務之間的整合和數據交換來促進軟體開發，使得開發更加方便靈活。
儘管有多種 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 APIs 依賴於預先定義的端點，透過 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 實施必須有兩個部分：模式和解析器。
模式定義了可以通過 GraphQL 查詢檢索的數據類型及其字段：
例如，假設你有以下模式：
客戶端可以使用以下查詢查詢用戶的姓名、電子郵件、組織和角色：
這個查詢不僅僅擷取請求的字段（email 和 organizations），還在單一請求中檢索相關數據（roles）。
GraphQL 解析器是 GraphQL 伺服器中的一個關鍵元件，用於確定如何擷取或計算客戶端在 GraphQL 查詢中請求的數據。當客戶端發送查詢時，查詢中的每個字段都會匹配到一個解析器，這包含了擷取或計算該字段數據的邏輯。
在上面的例子中，模式的解析器可能如下：
有兩種解析器：根解析器和字段解析器。
GraphQL 支持三種操作類型：查詢、變更和訂閱。
查詢：用於讀取數據。變更：用於寫入數據，包括添加、更改和刪除數據的操作。訂閱：用於請求數據的持久連接，允許客戶端聲明其感興趣的事件類型和應返回的數據。GraphQL 和 REST API 是用於在不同的 Web 服務之間交換數據的工具，但由於它們在解決問題的方法上的不同，以下是它們之間的主要差異：
REST API 通常會過度獲取或不足獲取數據，因為端點返回的響應是固定的。GraphQL 通過讓客戶端請求所需的確切數據來解決這一問題，減少不必要的數據傳輸。這使得 GraphQL 非常適合於數據需求複雜的應用程序，例如行動或低頻寬環境。
想像上面的例子，你需要獲取用戶的靜態數據、用戶所屬的組織和角色。使用 REST API，你需要向不同的端點發送多次請求以獲得所有數據。然而，使用 GraphQL，你可以在一次請求中獲取所有數據。
REST 的端點為基礎的結構直觀且適用於簡單應用程序和標準的 CRUD 操作。這是因為 REST APIs 是設計為資源為中心的，每個端點表示一個特定資源。這種方法的主要限制在於它不允許快速迭代和客戶端需求的變更。每當對客戶端進行更改時，必須更新伺服器以適應新需求，無論是增加新的端點還是更新現有的端點。這往往會導致大量冗余的端點和複雜的 API 版本管理。
相比之下，GraphQL 更加靈活，允許客戶端請求所需的數據。這種靈活性在客戶端需求經常變化的情況下特別有用，因為它消除了修改伺服器端 API 實現的需要。客戶端可以請求新的字段或嵌套數據，而不需要變更服務器。
儘管在數據獲取方面 GraphQL 更加高效和靈活，但它也有一些缺點。主要問題之一是緩存。
由於 REST API 的成熟生態系統，因其無狀態和標準化的特性，可以輕鬆在伺服器和客戶端層面緩存響應。這可以顯著減少對伺服器的請求數量，並提高性能。
然而，由於其靈活性，許多適用於 REST API 的緩存技術不適用於 GraphQL。必須根據具體使用情況在客戶端處理緩存，這會給客戶端開發帶來額外的工作量。
| 名稱 | 優點 | 缺點 |
|---|---|---|
| REST API | - 簡單且廣泛採用，擁有豐富的工具和社區支持。 - 清晰的結構，初學者容易理解。 - 使用 HTTP 標準，內置了緩存支持。 | - 過度獲取或不足獲取數據。 - 變更通常需要創建新版本，增加維護開銷。 |
| GraphQL | - 精確的數據獲取提高了性能和效率。 - 模式演化減少了版本管理的需求。 - 強大的工具，如自省和類型檢查，增強了開發體驗。 | - 與 REST 相比更為複雜的設定和學習曲線。 - 需要自定義的緩存解決方案，因為它不依賴於 HTTP 緩存。 - 單端點設計可能使得調試和監控更加複雜。 |
儘管 GraphQL 近年來作為一個新手取得了強勁的勢頭，但由於其原子設計和嚴謹性，REST API 長期以來仍然具有重大意義。
REST 和 GraphQL 滿足不同的需求，並在不同的場景中表現出色。REST 的簡單性使其成為簡單應用程序和微服務的理想選擇。GraphQL 在需要靈活和高效的數據檢索、尤其是在具有多樣客戶端或數據之間復雜關聯的應用程序中脫穎而出。在這兩者之間的選擇取決於專案的具體需求、團隊專業知識和長期的可擴展性需求。