你可能聽説過 GraphQL,但對它與 REST 的區別還不完全確定。今天我們將介紹 REST 和 GraphQL 的一些基本原理,以及它們的不同使用場景。
GraphQL 作為 REST API 的替代品越來越受歡迎,不過它不一定是完全的“替代品”。
根據你的使用情景,你需要在 GraphQL、REST API,或者兩者結合之間進行選擇。讓我們比較一下 REST 和 GraphQL,並瞭解一些 GraphQL 的優點,以便得出更明智的結論。
REST APIs
REST(表述性狀態轉移)API 是一種適用於應用程序接口(API)的架構風格,它使用 HTTP 請求來訪問和使用數據。該數據可用於 GET、PUT、POST 和 DELETE 操作,這些操作分別對應於資源的讀取、更新、創建和刪除。
RESTful API 使用 HTTP 方法來執行 CRUD(創建、讀取、更新和刪除)過程。 為了方便緩存、AB 測試、認證等過程,HTTP 頭部向客户端和服務器提供信息。
HTTP 主體包含客户端希望傳輸到服務器的數據,例如請求的有效負載。
GraphQL APIs
GraphQL 是一種用於 API 的查詢語言,並且是一種用現有數據來滿足這些查詢的運行時。GraphQL 提供了一個完整且易於理解的 API 數據描述,允許客户端準確獲取所需的數據,方便 API 的演進,並支持強大的開發者工具。Twitter、Expedia、Shopify 等知名公司已廣泛採用 GraphQL,GraphQL 主要由 GraphQL 基金會維護和開發。
GraphQL 與 REST 的對比
GraphQL 和 REST API 之間的主要區別在於,GraphQL 是一種查詢語言,而 REST 是一種用於網絡軟件的架構概念。
GraphQL 和 REST 在數據傳遞方式上也有很大不同。在 REST 架構中,客户端提交 HTTP 請求,數據以 HTTP 響應的形式返回。在 GraphQL 架構中,客户端提交查詢以獲取數據。
常見場景
REST APIs
假設你有一個用於獲取學生數據的 API。在典型的 REST 場景中,請求/響應可能如下所示:
// HTTP請求
GET api/students/1 || api/students?id=1
// HTTP響應
{
"id": 1,
"name": "john doe",
"class": 3,
"age": 11
}
在上面的例子中,發送到服務器的請求返回的是關於 ID 為 1 的學生的所有數據的對象。 由於 REST 的過度提取特性,這可能會花費較長時間,具體取決於數據的大小。
GraphQL
在 GraphQL 中,數據是通過嚴格列出所需字段來獲取的。這樣限制了一次獲取所有數據。請參考下面的 GIF,瞭解使用 GraphQL 獲取用户數據的方式。
在選擇 GraphQL 和 REST 時需要考慮的因素
安全性
REST API 使用 HTTP,允許通過傳輸層安全協議(TLS)進行加密,並提供多種API認證選項。TLS 確保在兩個系統之間傳輸的數據是私密且未被篡改的。支持 JavaScript 對象表示法(JSON)的網絡令牌完成 HTTP 認證過程,以便從 Web 瀏覽器安全地傳輸數據。
GraphQL 的安全控制不如 REST API 那樣成熟。為了利用 GraphQL 中的現有功能(如數據驗證),開發者需要設計新的認證和授權技術。
易用性
REST API 使用 URI 和 HTTP 方法,當訪問新的端點時,API 很難預測會發生什麼。REST 沒有指定的版本控制要求,因此各個提供者可以自行決定方法。
使用 GraphQL,你可以發送請求到 API 並接收到精確的響應,無需額外的添加。因此,GraphQL 查詢提供了非常可預測的響應,具有良好的易用性。GraphQL 採用簡單的方法,不需要對 API 進行版本控制。
性能
開發者可以通過 GraphQL 一次 API 請求來獲取數據。為了避免數據的不足獲取或過度獲取,靈活的樣式定義了信息請求的結構,並從服務器返回相同的結構。
與 GraphQL 相比,REST API 具有固態數據結構,可能首先返回不相關的信息(過度獲取)。由於請求需要時間來到達適當的數據並傳遞相關信息,開發者必須進行多次調用。
緩存
所有 REST API 的 GET 端點都可以在服務器或通過 CDN 緩存。它們也可以被客户端存儲以便常規使用,並且被瀏覽器緩存。GraphQL 通常通過一個單一的端點(通常是/graphql)提供,與 HTTP 規範有差異。這導致查詢不能像 REST API 一樣被緩存。
然而,由於可用工具,客户端的緩存比 REST 更優。一些使用緩存層的客户端(如 Apollo Client,URQL)利用 GraphQL 的模式和類型系統,在客户端保留緩存。
錯誤處理
每個 GraphQL 請求,無論成功還是錯誤,都會返回狀態碼 200。這與 REST API 不同,後者的每個狀態碼都指向特定類型的響應。
| 狀態碼 | REST | GraphQL |
|---|---|---|
| 200 | Ok | Ok |
| 400 | Bad Request | - |
| 401 | Unauthorized | - |
REST API 的錯誤可以是 200 以外的任何代碼,處理錯誤的客户端應瞭解所有可能的代碼。
GraphQL 中任何合法的答覆都應為 200,包括數據和錯誤響應。客户端工具將有助於更有效地管理錯誤。錯誤作為響應主體的一部分,在特定的 errors 對象下處理。
結論
讓我們回顧一下上述討論的內容。
| REST | GraphQL |
|---|---|
| 被廣泛視為設計 API 的傳統標準的架構風格 | 一種用於解決集成 API 時常見問題的查詢語言 |
| 簡化與多個端點的工作需要昂貴的自定義中間件 | 允許模式拼接和遠程數據獲取 |
| 不提供類型安全性或自動生成的文檔 | 提供類型安全性和自動生成的文檔 |
| 響應輸出通常是 XML、JSON 和 YAML | 響應輸出為 JSON |
| 支持多個 API 版本 | 不需要 API 版本控制 |
| 自動使用緩存 | 缺乏內置緩存機制 |
| 通過一組 URL 部署,每個 URL 暴露單一資源 | 通過單一端點部署,通過該端點提供暴露服務的全部功能 |
| 使用服務器驅動的架構 | 使用客户端驅動的架構 |
通過以上精心整理的差異,希望你能根據使用場景選擇合適的技術。
- 源於:https://dev.to/documatic/rest-api-vs-graphql-1a0n