REST vs GraphQL：差別在哪裡？該用哪一個？

REST 與 GraphQL 是兩種設計 API 的方式，也就是你的應用程式畫面（或其他程式）向後端請求資料時，所約定的做法。使用 REST 時，每種資料各有獨立的網址，例如 /customers 或 /orders，每個網址回傳固定格式的資料。使用 GraphQL 時，通常只有一個網址，呼叫端送出查詢，列出它想取回的確切欄位。對大多數用 AI 建構的應用程式來說，REST 是較簡單、也較好的預設選擇。

用 AI 建構時為什麼要懂這個

當你向 AI 建構工具要求「一個有後端的應用程式」時，它必須決定前端與後端如何溝通。你不需要每次都自己決定，但會在程式碼、文件以及連接外部服務時看到這些術語。有些服務只提供一種風格：許多服務提供 REST API，而 Shopify 與 GitHub 等則同時提供或偏好 GraphQL。了解兩者的差異，能幫助你看懂眼前的內容，並避免加入用不到的複雜度。如果「API」對你來說還很陌生，請先閱讀什麼是 API。

日常生活的比喻

REST 就像餐廳的套餐。 每道菜（端點）都是照廚房設計好的樣子端出來。點了「客戶」這道菜，你會拿到整盤東西，包括姓名、電子郵件、地址、註冊日期，即使你只想要姓名。想連同客戶最近的訂單一起拿？那就是另一道菜。

GraphQL 則像向同一位服務生單點。 你把想要的內容寫下來：「客戶的姓名，以及他最近三筆訂單的日期和金額。」一次點餐、一盤上桌，只有你要求的內容。但廚房必須事先準備好，能處理顧客可能寫下的任何組合。

同一個請求，兩種做法

假設客戶頁面需要客戶的姓名，以及他最近的三筆訂單。

使用 REST，通常需要兩次請求：

GET /api/customers/42
GET /api/customers/42/orders?limit=3

第一個回應可能包含比頁面所需更多的內容：

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

使用 GraphQL，只需要一次請求，通常是對單一端點（例如 /graphql）發出 POST，並附上查詢：

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

回應會精確對應查詢的結構：

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

兩者回傳的都是 JSON。差別在於由誰決定格式：在 REST 中由伺服器決定；在 GraphQL 中由呼叫端決定，但仍受伺服器的 schema 所允許的範圍限制。

並排比較

各自適合的情境

以下情況選擇 REST：

• 你在建構一般應用程式：預約系統、CRM、儀表板、商店。
• 一個前端與一個後端溝通，而且兩端都由你掌控。
• 你希望除錯、快取與保護都最簡單。
• 其他服務會呼叫你的應用程式（Webhook 與大多數整合都預期 REST 風格的端點）。

以下情況可考慮 GraphQL：

• 幾個不同的用戶端（網站、行動應用程式、合作夥伴整合）需要同一份資料的不同部分，而且差異很大。
• 你的資料彼此高度相連（商品、規格變體、評論、賣家、庫存），畫面需要以多種方式組合這些資料。
• 你要使用的服務以 GraphQL 作為主要 API。

一個實用的原則：如果你不確定是否需要 GraphQL，那你大概還不需要。之後再加入比移除容易。

關鍵術語

常見的誤解

• 「GraphQL 比較新，所以比較好。」 它是用來解決特定問題的。對於只有單一前端的單一應用程式，它通常只會增加工作，帶來的好處有限。
• 「GraphQL 就是資料庫。」 不是。它是 API 層；在它後面，伺服器仍然要從你的資料庫讀取資料。
• 「GraphQL 一定比較快。」 請求次數變少，在慢速的行動網路上可能有幫助，但沒有限制的查詢可能會載入大量資料。效能取決於後端。
• 「REST 代表嚴格的標準。」 實務上，「REST API」通常泛指以資源網址加上 HTTP 方法與 JSON 的設計。許多良好的 API 都會彎曲正式規則。
• 「狀態碼 200 代表成功。」 使用 GraphQL 時，請檢查 errors 欄位，因為請求可能部分失敗，卻仍然回傳 200。

可以問你的 AI 建構工具

• 「除非有明確理由，請使用簡單的 REST API 搭配 JSON；如果你認為需要 GraphQL，請說明原因。」
• 「列出每個端點、它會回傳什麼，以及誰被允許呼叫它。」
• 「客戶頁面只回傳該頁面會使用的欄位。」
• 「為列表端點加入分頁，讓它們不會一次回傳數千筆資料。」
• 「這個服務只提供 GraphQL API，請從伺服器呼叫它，把金鑰存放在機密設定中，並只請求我們需要的欄位。」
• 「回傳正確的 HTTP 狀態碼與 JSON 格式的錯誤訊息。」

Mythex 中的 REST 與 GraphQL

Mythex 的文件包含一份建構 REST API 後端的範例，附有起始提示詞；後端可以與你的網頁應用程式一起在 Node、Python（FastAPI）、C# 或 Java 中執行。文件中沒有 GraphQL 範本，因此如果你需要，請明確要求，並說明原因。呼叫第三方 GraphQL API 的方式與呼叫其他外部服務相同，請參閱整合任何 API。相關閱讀：前端與後端與如何建構 REST API。

常見問題