簡(jiǎn)介

RESTful 和 GraphQL API 是構(gòu)建 Web API 的兩種流行選擇，各有其優(yōu)勢(shì)和劣勢(shì)。讓我們更近距離地了解一下 RESTful 和 GraphQL API，它們的區(qū)別，以及在何時(shí)選擇其中一種。

RESTful API 已經(jīng)存在了一段時(shí)間，并且通常被廣泛使用，而 GraphQL 是近年來(lái)變得流行的較新技術(shù)。

第一部分：什么是 RESTful API？

RESTful API 遵循一組規(guī)則和約束，規(guī)定了 API 應(yīng)該如何設(shè)計(jì)。

1.使用標(biāo)準(zhǔn)的 HTTP 方法

它們使用標(biāo)準(zhǔn)的 HTTP 方法，例如 GET、POST、PUT、PATCH 和 DELETE，對(duì)資源執(zhí)行操作，數(shù)據(jù)通常以 JSON 格式 返回。

2.是無(wú)狀態(tài)的

RESTful API 是無(wú)狀態(tài)的，這意味著服務(wù)器不會(huì)在請(qǐng)求之間存儲(chǔ)任何客戶端上下文。相反，每個(gè)請(qǐng)求都包含服務(wù)器處理所需的所有信息。這使得 RESTful Web 服務(wù)高度可伸縮，因?yàn)樗鼈兛梢蕴幚泶罅空?qǐng)求而無(wú)需為會(huì)話管理負(fù)擔(dān)。

3.具有 URL 約定

RESTful URL 命名約定 的主要原則之一是在 URL 路徑中使用名詞而不是動(dòng)詞。例如，不適合使用 /get-user-profile 這樣的 URL，更適合使用 /users/{user_id}/profile。該 URL 使用名詞 users 表示用戶資源的集合，并使用路徑參數(shù) user_id 來(lái)標(biāo)識(shí)要訪問(wèn)的特定用戶資源。

第二部分：什么是 GraphQL？

GraphQL 是一個(gè)用于 API 的 查詢語(yǔ)言，允許客戶端定義其需要的數(shù)據(jù)的形狀和結(jié)構(gòu)。使用 GraphQL，客戶端可以向服務(wù)器發(fā)出單個(gè)請(qǐng)求，并準(zhǔn)確獲取它們要求的數(shù)據(jù)，而沒(méi)有其他多余的數(shù)據(jù)。

1.提供單個(gè)端點(diǎn)

與 RESTful API 不同，GraphQL 提供一個(gè) 單個(gè)端點(diǎn)，通常是 /graphql，它始終接受 POST 請(qǐng)求。客戶端向此端點(diǎn)發(fā)送單個(gè)請(qǐng)求，服務(wù)器將根據(jù)通過(guò)請(qǐng)求體發(fā)送的查詢或變更響應(yīng)請(qǐng)求的數(shù)據(jù)。

這種方法使得管理和版本化 API 變得容易，因?yàn)樗懈亩伎梢栽谝粋€(gè)地方進(jìn)行。

2.是無(wú)狀態(tài)的

GraphQL API 也是無(wú)狀態(tài)的，服務(wù)器不存儲(chǔ)任何客戶端數(shù)據(jù)，每個(gè)請(qǐng)求都包含請(qǐng)求查詢中的所有信息。

第三部分：比較 RESTful 和 GraphQL API

RESTful 和 GraphQL API 在設(shè)計(jì)和查詢 API 方面采用不同的方法。讓我們根據(jù)一些關(guān)鍵因素進(jìn)行比較：

1.數(shù)據(jù)獲取

RESTful API 遵循嚴(yán)格的請(qǐng)求-響應(yīng)循環(huán)，其中來(lái)自客戶端的每個(gè)請(qǐng)求都導(dǎo)致服務(wù)器的單個(gè)響應(yīng)。這意味著客戶端通常需要進(jìn)行多個(gè)請(qǐng)求，從服務(wù)器獲取相關(guān)數(shù)據(jù)，從而導(dǎo)致過(guò)度獲取或不足獲取數(shù)據(jù)。

GraphQL 相反，允許客戶端僅請(qǐng)求他們需要的數(shù)據(jù)，而不是其他多余的數(shù)據(jù)。客戶端可以指定他們需要的數(shù)據(jù)的結(jié)構(gòu)，服務(wù)器會(huì)準(zhǔn)確返回該數(shù)據(jù)，減少 過(guò)度獲取 和 不足獲取 數(shù)據(jù)。

2.模式定義

在 RESTful APIs 中，服務(wù)器定義數(shù)據(jù)模式，客戶端需要解析返回的數(shù)據(jù)以理解模式。這可能導(dǎo)致客戶端和服務(wù)器之間的耦合，因?yàn)榉?wù)器上的模式更改需要在客戶端上進(jìn)行相應(yīng)的更改。

GraphQL 相反，具有強(qiáng)類型模式，定義了 API 中可用的數(shù)據(jù)。客戶端可以使用此模式驗(yàn)證其查詢并理解它們接收到的數(shù)據(jù)，減少客戶端和服務(wù)器之間的耦合。

3.緩存

RESTful API 使用 HTTP 緩存頭 具有 內(nèi)建的緩存機(jī)制。這允許客戶端緩存響應(yīng)并避免向服務(wù)器發(fā)出不必要的請(qǐng)求。

GraphQL 沒(méi)有內(nèi)建的緩存機(jī)制，但 客戶端可以使用第三方庫(kù)實(shí)現(xiàn)緩存策略。

4.性能

RESTful API 在客戶端需要多次請(qǐng)求相關(guān)數(shù)據(jù)時(shí)可能遇到性能問(wèn)題。這可能導(dǎo)致增加的延遲和網(wǎng)絡(luò)流量。

GraphQL 通過(guò)**在單個(gè)：

請(qǐng)求中僅獲取所需數(shù)據(jù)**，可以提高性能并減少網(wǎng)絡(luò)流量。但是，如果不小心，優(yōu)化不良的查詢可能會(huì)導(dǎo)致更多性能問(wèn)題，并嚴(yán)重影響服務(wù)器。從這個(gè)角度來(lái)看，GraphQL 的最大優(yōu)勢(shì)也可能是它的最大劣勢(shì)。

第四部分：你應(yīng)該選擇哪個(gè)？

在 RESTful 和 GraphQL API 之間的選擇取決于您的具體用例。RESTful API 適用于需要高可伸縮性的簡(jiǎn)單應(yīng)用程序，而 GraphQL 則適用于具有不同數(shù)據(jù)需求的復(fù)雜應(yīng)用程序。

RESTful 和 GraphQL API 都有各自的優(yōu)勢(shì)和劣勢(shì)。請(qǐng)記住，在兩者之間進(jìn)行選擇并不總是二選一的情況，有時(shí)混合使用可能是最佳選擇。

資源

• GraphQL 文檔：https://graphql.org/
• 什么是 RESTful API：https://aws.amazon.com/what-is/restful-api/