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

# 比較 REST 和 GraphQL
<a name="comparing-rest-graphql"></a>

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

GraphQL 和 REST 有幾個關鍵特性：

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

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

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

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

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

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

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

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

1. **請求結構和資料擷取**

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

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

1. **伺服器端結構描述**

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

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

1. **版本控制**

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

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

1. **錯誤處理** 

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

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

1. **使用案例**

   REST 更適合：
   + 具有較不複雜資料需求的小型應用程式。
   + 所有用戶端以類似方式使用資料和操作的情況。
   + 無需複雜資料查詢的應用程式。

   GraphQL 更適合：
   + 頻寬有限的案例，其中將請求和回應降至最低至關重要。
   + 具有多個資料來源且需要在單一端點合併的應用程式。
   + 用戶端請求有顯著差異且預期不同回應結構的案例。

   請注意，您可以在單一應用程式中使用 GraphQL 和 REST APIs 進行不同的功能領域。此外，您可以升級 RESTful API 以包含 GraphQL 功能，而無需完全重寫。如需範例，請參閱[如何為 AWS 資料來源建置 GraphQL 解析程式](https://aws.amazon.com/graphql/resolvers/)。