Stories

Detail Return Return

GraphQL 和 REST API:選擇最佳數據獲取方案 - Stories Detail

你可能聽説過 GraphQL,但對它與 REST 的區別還不完全確定。今天我們將介紹 REST 和 GraphQL 的一些基本原理,以及它們的不同使用場景。

GraphQL 作為 REST API 的替代品越來越受歡迎,不過它不一定是完全的“替代品”。

根據你的使用情景,你需要在 GraphQL、REST API,或者兩者結合之間進行選擇。讓我們比較一下 REST 和 GraphQL,並瞭解一些 GraphQL 的優點,以便得出更明智的結論。

REST APIs

rest api

REST(表述性狀態轉移)API 是一種適用於應用程序接口(API)的架構風格,它使用 HTTP 請求來訪問和使用數據。該數據可用於 GET、PUT、POST 和 DELETE 操作,這些操作分別對應於資源的讀取、更新、創建和刪除。

RESTful API 使用 HTTP 方法來執行 CRUD(創建、讀取、更新和刪除)過程。 為了方便緩存、AB 測試、認證等過程,HTTP 頭部向客户端和服務器提供信息。

HTTP 主體包含客户端希望傳輸到服務器的數據,例如請求的有效負載。

GraphQL APIs

graphql apis

GraphQL 是一種用於 API 的查詢語言,並且是一種用現有數據來滿足這些查詢的運行時。GraphQL 提供了一個完整且易於理解的 API 數據描述,允許客户端準確獲取所需的數據,方便 API 的演進,並支持強大的開發者工具。Twitter、Expedia、Shopify 等知名公司已廣泛採用 GraphQL,GraphQL 主要由 GraphQL 基金會維護和開發。

GraphQL 與 REST 的對比

diff

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 獲取用户數據的方式。

gif1

在選擇 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
user avatar toopoo Avatar huanjinliu Avatar howiecong Avatar baqidemakebei Avatar gaoxingdehongshaorou_clgwsy Avatar aws_aidevcommunity Avatar
Favorites 6 users favorite the story!
Favorites

Add a new Comments

Some HTML is okay.