2023-09-22發表Web Development9 分鐘讀完 (大約1295個字)

GraphQL 是什麼？ GraphQL & RESTful API 的差異

近幾個月求職的時候越來越常在 JD 和面試的時候被問到關於 GraphQL 的相關概念，所以就決定開始來研究 GraphQL 究竟是什麼？它能應用到的場景是哪些？
一起來一探究竟囉！

什麼是 GraphQL ?

A query language for your API.

進入官網斗大的標題就直接明瞭的告訴你了，不過我必須承認我在研究這個主題時看到這句話其實是滿頭問號的。
原因很簡單，因為我不知道為什麼需要查詢我的 API ，所以在解釋 GraphQL 前，我們應該要先來了解一下 GraphQL 是為了解決什麼問題而誕生的？

還沒有 GraphQL 的時代

在 GraphQL 出現之前，API 設計通常會選擇使用 RESTful 的設計風格，這種風格的 API 具有固定的端點結構且每個端點代表一個資源，並且使用 HTTP 方法（ GET / POST / PUT / DELETE 等 methods ）執行操作。這種方式有其優勢，但也存在一些限制，特別是當客戶端需要不同組合的數據或自定義查詢時。

這邊的端點指的就是 API 中固定的 URL 結構，像是：

獲取所有用戶：/api/users

獲取單個用戶：/api/users/{userId}

GraphQL 解決的問題

所以 GraphQL 的核心功能之一：讓用戶可以根據自身的需求自定義要查詢的項目，而不需要像 RESTful API 遵循固定的端點結構，讓其他不相關的資料也一併回傳。
看一下下面的 GraphQL 的 request 範例：

POST /graphql
Content-Type: application/json

{
  "query": "{
    user(id: 1) {
      id
      name
      email
    }
  }"
}

可以發現我們的 API 端點 url 統一為 /graphql ，而在 request 中我們可以直接指定我們只要 id 為 1 的使用者資料，其他的使用者資料都不需要回傳過來。

這邊可能有人會好奇說，這樣不是跟 RESTful API 一樣嗎？只是我在 url 上面要多帶一個 id 的參數就好。
不過這也直接點出了 RESTful API 的劣勢，你必須根據請求端需要的資料來做設計不同的端點，但是 GraphQL 在端點的部分都統一，讓我們直接從 client 端去選擇自己要收到的 response 是什麼？

所以 GraphQL 到底是？

GraphQL 不只是一種查詢 API 的語言，它也是用於建立靈活、高效、精確數據API的工具，同時還是一個執行引擎，用來負責解析和執行這些查詢。

希望透過上面的說明大家可以更知道 GraphQL 在做什麼？
因為我之前很常把它跟 RESTful API 搞混，所以才特別把這些我當初困惑的問題都整理出來。

GraphQL 和 RESTful API 的差異

差異	GraphQL	RESTful API
API 端點	用戶可以通過一個單一的端點發出具體的查詢來擷取所需的數據，而不需要多個不同的端點。	使用多個不同的端點（資源路徑）來執行特定操作。每個端點通常代表一個特定的資源和操作（GET、POST、PUT、DELETE等）。
過度請求	使用查詢語言使得過度請求的狀況出現時相較容易控制，因為 client side 可以精確的指定所需要的資料即可。	如果遇到過度請求問題通常需要通過創建不同的端點或自定義參數來解決。
版本管理	通常不需要版本管理，因為 client side 可以根據需求撰寫新的 query。	比較需要版本管理，以確保現有的 client side 能正確取得 response，且當 API 發生新的需求必須變更時，通常就要創一個新版本的端點。

結語

直接引用 ChatGPT 幫我做的結論

GraphQL 是一個用於設計和實現API的工具，它的核心是 查詢語言和執行引擎 ，讓客戶端能夠根據其需求自定義查詢。而 RESTful API 則是一種特定的 API 設計風格，它遵循 REST 原則，使用 HTTP 方法來執行操作。
這兩者在設計和使用上有很大不同，可以根據項目的需求選擇適當的工具和風格。

總算搞懂了這個工具到底在做些什麼？
雖然目前都還沒在工作上接觸到，不過對 GraphQL 的印象確實很不錯，希望之後有機會可以實際使用到。
那我們下次見ʘ‿ʘ

參考資料