比較 REST 和 GraphQL - AWS AppSync GraphQL

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

比較 REST 和 GraphQL

APIs（應用程式程式設計界面） 在促進應用程式之間的資料交換方面扮演重要角色。如前所述，已出現兩種設計 APIs的重要方法：GraphQL 和 REST。雖然兩者都具有啟用用戶端與伺服器通訊的基本目的，但它們在實作和使用案例中有很大的差異。

GraphQL 和 REST 有幾個關鍵特性：

  1. Client-Server 模型：兩者都使用用戶端-伺服器架構進行資料交換。

  2. 無狀態：兩個 都不會在請求之間維護用戶端工作階段資訊。

  3. HTTP 型：兩者通常使用 HTTP 做為基礎通訊協定。

  4. 資源導向設計：兩者都圍繞資源設計其資料交換，這是指用戶端可以透過 API 存取和操作的任何資料或物件。

  5. 資料格式彈性：JSON 是兩者中最常使用的資料交換格式，但也支援其他格式，例如 XML 和 HTML。

  6. 語言和資料庫無關：兩者都可以使用任何程式設計語言或資料庫結構，使其具有高度互通性。

  7. 快取支援：兩者都支援快取，可讓用戶端和伺服器存放經常存取的資料，以提升效能。

在分享一些基本原則時，GraphQL 和 REST 的 API 設計和資料擷取方法有顯著差異：

  1. 請求結構和資料擷取

    REST 使用不同的 HTTP 方法 (GET、POST、PUT、DELETE) 對資源執行操作。這通常需要不同資源的多個端點，這可能會導致資料擷取的效率低下。例如，執行 GET 操作來擷取使用者的資料可能會導致資料過度擷取或擷取不足。若要取得正確的資料，可能會呼叫截斷或多個操作。

    GraphQL 對所有操作使用單一端點。它依賴查詢來擷取資料和變動來修改資料。用戶端可以使用查詢來擷取其在單一請求中所需的確切資料，從而透過將資料傳輸降至最低來降低網路開銷。

  2. 伺服器端結構描述

    REST 不需要伺服器端結構描述，但可以選擇性地定義結構描述，以實現高效的 API 設計和文件。

    GraphQL 使用強類型伺服器端結構描述來定義資料和資料服務。以 GraphQL 結構描述定義語言 (SDL) 編寫的結構描述包含每個物件的物件類型和欄位，以及定義每個欄位操作的伺服器端解析程式函數。

  3. 版本控制

    REST 通常在 URL 中包含版本控制，這可能會導致同時維護多個 API 版本。版本控制不是強制性的，但有助於防止重大變更。

    GraphQL 透過要求回溯相容性來提升 API 的持續演變，而無需明確版本控制。刪除的欄位會傳回錯誤訊息，而棄用標籤則會逐步淘汰舊欄位並傳回警告訊息。

  4. 錯誤處理

    REST 類型較弱，需要將錯誤處理內建到周圍的程式碼中。這可能不會自動識別與類型相關的錯誤 （例如，將數字剖析為文字）。

    相較之下，GraphQL 是強式輸入，需要全面的結構描述定義。這可讓您的服務自動識別許多具有高度詳細資訊的請求錯誤。

  5. 使用案例

    REST 更適合：

    • 具有較不複雜資料需求的小型應用程式。

    • 所有用戶端以類似方式使用資料和操作的情況。

    • 沒有複雜資料查詢需求的應用程式。

    GraphQL 更適合：

    • 頻寬有限的案例，其中將請求和回應降至最低至關重要。

    • 具有多個資料來源且需要在單一端點合併的應用程式。

    • 用戶端請求有顯著差異且預期不同回應結構的案例。

    請注意，您可以在單一應用程式中對不同的功能領域使用 GraphQL 和 REST APIs。此外，您可以升級 RESTful API 以包含 GraphQL 功能，而無需完全重寫。如需範例，請參閱如何為 AWS 資料來源建置 GraphQL 解析程式。