GraphQL 和 REST 有何區別？

GraphQL 和 REST 都是常用的 API 架構樣式，支援在用戶端-伺服器模型的不同服務或應用程式之間交換資料。

API 有助於存取資料和資料操作，如下所示：

1. 用戶端將 API 請求傳送至伺服器上的一個端點或多個端點
2. 伺服器提供包含資料、資料狀態或錯誤代碼的回應

REST 和 GraphQL 允許您透過 API，在單獨的應用程式、服務或模組上建立、修改、更新和刪除資料。 使用 REST 開發的 API 被稱為 RESTful API 或 REST API。那些使用 GraphQL 開發的只是 GraphQL API。

前端和後端團隊使用這些 API 架構，來建立模組化且可存取的應用程式。使用 API 架構有助於保持系統安全、模組化和可擴展性。這也讓系統具有更高效能，並且更容易與其他系統整合。

接下來，我們討論 GraphQL 與 REST 之間的一些其他相似之處。

閱讀有關 API 的內容 »

架構

REST 和 GraphQL 都實作了多個常見的 API 架構原則。例如，以下是其共用的原則：

• 兩者都為無狀態，因此伺服器不會在請求之間儲存回應歷史記錄
• 兩者都使用用戶端-伺服器模型，因此，單一用戶端的請求會導致單一伺服器的回覆
• 兩者都以 HTTP 為基礎，因為 HTTP 是基礎的通訊協議

以資源為基礎的設計

REST 和 GraphQL 都設計了圍繞資源進行的資料交換。資源是指用戶端可透過 API 存取和操作的任何資料或物件。每項資源自身都有不重複的識別符 (URI)，以及一組用戶端可以在其上執行的操作 (HTTP 方法)。

例如，假設一個社交媒體 API，使用者可在其中建立和管理張貼。在以資源為基礎的 API 中，張貼將會是一項資源。它自身有不重複的識別符，例如，/posts/1234。它還具有一組操作，例如 GET，用於在 REST 中擷取張貼；或 query，用於在 GraphQL 中擷取張貼。

Data Exchange

REST 和 GraphQL 都支援類似的資料格式。

JSON 是所有語言、平台和系統都能理解的最常用的資料交換格式。伺服器將 JSON 資料傳回給用戶端。提供了其他資料格式，但較不常用，包括 XML 和 HTML。

同樣，REST 和 GraphQL 都支援快取。因此，用戶端和伺服器可以快取經常存取的資料，以提高通訊速度。

閱讀有關 JSON 的內容 »

語言與資料庫中立

GraphQL 和 REST API 都可以與任何資料庫結構和任何程式設計語言搭配使用，包括用戶端和伺服器端。這使其與任何應用程式高度互操作。

REST API 是應用程式通訊的架構概念。另一方面，GraphQL 是一項規範、一種 API 查詢語言，以及工具集。GraphQL 使用 HTTP 在單一端點上運作。

此外，REST 開發更專注於製作新的 API。同時，GraphQL 的重點是 API 的效能與靈活性。

接下來，我們將介紹更多不同之處。

用戶端請求

以下是 REST 請求用於工作的內容： 

• 確定動作的 HTTP 動詞
• 識別要對其執行 HTTP 動詞的資源 URL
• 如果您想要在現有伺服器端資源內建立或修改物件，則要剖析的參數和值

例如，您可以使用 GET 從資源中取得唯讀資料，使用 POST 來新增資源項目，或使用 PUT 來更新資源。

相較之下，以下是 GraphQL 請求使用的內容：

• 取得唯讀資料的查詢
• 修改資料的變動
• 訂閱以接收事件型更新或串流資料更新

資料格式描述您希望伺服器傳回資料的方式，包括與伺服器端結構描述相符的物件和欄位。您還可以輸入新資料。在內部，GraphQL 將每個用戶端請求做為 POST HTTP 請求傳送。

傳送給用戶端的資料

在 REST 架構下，資料從伺服器指定的整個資源結構中的伺服器傳回給用戶端。下列範例顯示了 REST 和 GraphQL 中傳回的資料。

REST 中傳回的資料範例

在 REST 中，GET/POST 傳回下列內容︰

[

  {

    "id": 1,

    "title": "First Post",

    "content": "This is the content of the first post."

  },

  {

    "id": 2,

    "title": "Second Post",

    "content": "This is the content of the second post."

  },

  {

    "id": 3,

    "title": "Third Post",

    "content": "This is the content of the third post."

  }

]

GraphQL 中傳回的資料範例

當您使用 GraphQL 時，只會傳回用戶端給定結構中指定的資料。

GET /graphql?query{post(id: 1) {id title content}} returns only the first post:

{

  "data": {

    "posts": [

      {

        "id": "1",

        "title": "First Post",

        "content": "This is the content of the first post."

      },

]}}

伺服器端結構描述

GraphQL 使用伺服器端結構描述，來定義與 REST API 不同的資料和資料服務。

以 GraphQL 結構定義語言撰寫的結構描述包含下列詳細資訊：

• 屬於每個物件的物件類型和欄位
• 針對每個欄位定義操作的伺服器端解析程式函數

結構描述明確定義類型，以描述系統上所有可用的資料，以及用戶端如何存取或修改該資料。 

另一方面，REST API 不需要伺服器端結構描述。但是您可以選擇定義該結構描述，以實現有效的 API 設計、文件編製和用戶端開發。 

版本控制

隨著 API 的演進，其資料結構和操作可能會變更。針對不知道這些變更的用戶端，它可能會破壞其系統或引入未知的錯誤。

REST API 通常在 URL 中包括版本控制以解決此問題，例如 https://example.com/api/v1/person/12341。 但是，版本控制並非強制性，而且可能會導致錯誤。 

GraphQL 需要 API 向後相容性。因此，刪除的欄位會傳回錯誤訊息，或者那些具有已棄用標籤的欄位會傳回警告。

錯誤處理

GraphQL 是一種強類型 API 架構，這意味著它需要結構描述中有關資料、其結構和資料操作的詳細資訊。由於結構描述中的詳細資訊層級，系統可以自動識別請求錯誤並提供有用的錯誤訊息。 

REST API 是弱類型，您必須在周圍的程式碼中建置錯誤處理。例如，如果 PUT 請求數值剖析為文字而非整數，則系統不會自動識別錯誤。

在不執行完整重寫的情況下，可將 RESTful API 升級至 GraphQL API。

以下是該程序的概述：

1. 了解 RESTful API 的資料模型。若要執行此操作，請檢查每個 URL 資源中的資料形狀。
2. 從資料模型寫入 GraphQL 結構描述。
3. 判斷用戶端對資料執行了哪些作業，並將其納入結構描述。
4. 在結構描述每個欄位的伺服器端程式碼中，建立解析程式函數。
5. 使用解析程式和結構描述建立 GraphQL 伺服器。

在此之後，用戶端可以使用 GraphQL 或 REST 與您的 API 通訊。

閱讀有關如何建置 GraphQL 解析程式的內容 »

Amazon Web Services (AWS) 可協助您建置和提供更好的受管 API。

AWS AppSync 會建立無伺服器 GraphQL 以及發佈訂閱-(發佈/訂閱) API。其透過單一端點簡化應用程式的開發，以便安全地查詢、更新或發佈資料。

使用 AWS AppSync，您可以建立允許用戶端執行下列操作的 API：

• 透過單一網路呼叫與多個資料來源互動，例如 SQL、NoSQL、搜尋資料、REST 端點及微型服務
• 自動在行動和 Web 應用程式與雲端之間同步資料
• 在後端與連線用戶端之間廣播資料
• 存取物聯網 (IoT) 資料，在行動或 Web 應用程式中建置即時儀表板

同樣，Amazon API Gateway 是一種全受管的服務，可讓您輕鬆地建立、發佈、維護、監控和保護任何規模的 API。

以下是您可透過使用 API Gateway 獲益的方法：

• 為使用者提供 API 請求和回應的高速效能
• 授權存取您的 API
• 同時執行相同 API 的多個版本，快速重複執行、測試和發行新的版本
• 監控有關 API 呼叫、資料延遲和錯誤率的效能指標和資訊

立即建立帳戶，開始使用 AWS 上的 GraphQL 和 REST。