{
"name": "windeal",
"age": 25,
"email": "xxxx@163.com"
}

更新資源(PUT)

更新一個(gè)資源。例如,將 ID 為 1 的用戶信息更新為:

PUT /users/1
{
"name": "Jane",
"age": 30,
"email": "jane@example.com"
}

刪除資源(DELETE)

刪除一個(gè)資源。例如,刪除 ID 為 1 的用戶:

  1. DELETE /users/1

RESTful API的優(yōu)缺點(diǎn)

三、GraphQL API

GraphQL API 簡(jiǎn)介

GraphQL API官網(wǎng): https://graphql.org/

GraphQL API的基本概念是使用GraphQL語(yǔ)言來(lái)描述API的查詢能力。客戶端通過(guò)GraphQL語(yǔ)言來(lái)描述所需的數(shù)據(jù),而無(wú)需知道底層的數(shù)據(jù)結(jié)構(gòu)和存儲(chǔ)方式。然后,服務(wù)器會(huì)根據(jù)客戶端的請(qǐng)求生成響應(yīng),并將數(shù)據(jù)發(fā)送回客戶端。

GraphQL API遵循以下設(shè)計(jì)原則:

  1. 強(qiáng)類型:GraphQL是一種強(qiáng)類型的查詢語(yǔ)言,它的類型系統(tǒng)有嚴(yán)格的約束、具備清晰的層次關(guān)系。
  2. 單一端點(diǎn):所有的GraphQL API都從同一個(gè)端點(diǎn)獲取相應(yīng)的數(shù)據(jù)。
  3. 可組合性:客戶端可以通過(guò)組合不同的查詢來(lái)獲取所需的數(shù)據(jù)。
  4. 可預(yù)測(cè)性:GraphQL查詢語(yǔ)句在語(yǔ)法上是非常明確的,因此對(duì)于客戶端來(lái)說(shuō)是可以預(yù)測(cè)的。
  5. 客戶端驅(qū)動(dòng):GraphQL API由客戶端發(fā)起,客戶端控制數(shù)據(jù)傳輸和終端的兼容性。
  6. 自我描述的API:GraphQL API使用類型系統(tǒng)來(lái)描述其功能和數(shù)據(jù)類型,因而具有自我描述特性。

GraphQL API 示例

示例一:查詢博客文章列表

query {
posts {
id
title
author {
id
name
}
}
}

在這個(gè)示例中,我們查詢了博客文章列表,每篇文章都有一個(gè) ID、標(biāo)題和作者。作者包括 ID 和名字。這個(gè)查詢對(duì)于一個(gè)顯示所有博客文章的列表的應(yīng)用程序非常有用。

示例二: 創(chuàng)建新的博客文章

mutation {
createPost(input: {
title: "My new blog post"
content: "This is the content of my new blog post."
authorId: "123"
}) {
id
title
content
author {
id
name
}
}
}

在這個(gè)示例中,我們創(chuàng)建了一個(gè)新的博客文章。我們提供了文章的標(biāo)題、內(nèi)容和作者 ID。查詢返回了新創(chuàng)建的文章的 ID、標(biāo)題、內(nèi)容和作者。這個(gè)查詢對(duì)于創(chuàng)建新的博客文章的應(yīng)用程序非常有用。

GraphQL API 的優(yōu)缺點(diǎn)

  1. 高度定制化:GraphQL API允許客戶端請(qǐng)求特定的數(shù)據(jù),從而減少了不必要的數(shù)據(jù)傳輸,提高了性能。這使得客戶端能夠根據(jù)其需求選擇所需的數(shù)據(jù),從而提高了效率。
  2. 單一的入口點(diǎn):GraphQL API通過(guò)一個(gè)單一的入口點(diǎn)提供所有數(shù)據(jù),這使得客戶端更容易理解和使用API。這有助于簡(jiǎn)化客戶端的開發(fā)和維護(hù)工作。
  3. 更好的可擴(kuò)展性:GraphQL API的可擴(kuò)展性更強(qiáng),因?yàn)樗试S開發(fā)人員輕松地添加新的字段和類型,而無(wú)需更改現(xiàn)有的API。這使得API更容易適應(yīng)不斷變化的需求。
  1. 學(xué)習(xí)曲線:雖然GraphQL API具有許多優(yōu)點(diǎn),但它也有一個(gè)學(xué)習(xí)曲線。開發(fā)人員需要花費(fèi)一些時(shí)間學(xué)習(xí)如何使用GraphQL API,以及如何有效地使用它。
  2. 實(shí)現(xiàn)復(fù)雜性:雖然GraphQL API提供了很多優(yōu)勢(shì),但實(shí)現(xiàn)它可能會(huì)增加開發(fā)人員的工作量。例如,開發(fā)人員需要編寫自定義解析器和驗(yàn)證器,以確保API的正確性和安全性。
  3. 缺乏標(biāo)準(zhǔn)化:雖然REST API已經(jīng)成為Web開發(fā)的事實(shí)標(biāo)準(zhǔn),但GraphQL API仍然是一個(gè)相對(duì)較新的技術(shù)。這意味著它可能沒(méi)有那么多現(xiàn)有的工具和資源可供開發(fā)人員使用。

四、RPC API

RPC API 簡(jiǎn)介

RPC API官網(wǎng)  https://grpc.io/

RPC(Remote Procedure Call)API 是一種遠(yuǎn)程調(diào)用協(xié)議,它允許客戶端在不了解服務(wù)端實(shí)現(xiàn)細(xì)節(jié)的情況下,調(diào)用服務(wù)端上的函數(shù)或方法。RPC API 的主要特點(diǎn)是它可以跨越網(wǎng)絡(luò),實(shí)現(xiàn)不同計(jì)算機(jī)之間的通信和數(shù)據(jù)交換。

gRPC 是一個(gè)高性能、開源的 RPC 框架,它可以在多種環(huán)境中運(yùn)行,包括云端、數(shù)據(jù)中心和本地計(jì)算機(jī)。gRPC 使用 HTTP/2 協(xié)議進(jìn)行通信,并利用 Protocol Buffers 作為接口定義語(yǔ)言和消息交換格式,以實(shí)現(xiàn)高效的數(shù)據(jù)傳輸和低延遲。

gRPC 的特點(diǎn)包括:

  1. 高性能:gRPC 使用 HTTP/2 協(xié)議和 Protocol Buffers 序列化技術(shù),能夠?qū)崿F(xiàn)高效的數(shù)據(jù)傳輸和低延遲。
  2. 跨平臺(tái):gRPC 支持多種編程語(yǔ)言和平臺(tái),包括 C++、Java、Python、Go、C#、Node.js 等。
  3. 可擴(kuò)展性:gRPC 支持在多種環(huán)境中運(yùn)行,包括云端、數(shù)據(jù)中心和本地計(jì)算機(jī)。
  4. 安全性:gRPC 支持 SSL/TLS 加密,能夠保護(hù)數(shù)據(jù)傳輸?shù)陌踩浴?/li>
  5. 易用性:gRPC 提供了簡(jiǎn)單易用的 API,使得開發(fā)者可以輕松地實(shí)現(xiàn)遠(yuǎn)程調(diào)用功能。

RPC API示例

一個(gè)用戶信息查詢的示例:

定義接口:

syntax = "proto3";

service UserService {
rpc GetUserInfo (UserRequest) returns (UserResponse);
}

message UserRequest {
int32 user_id = 1;
}

message UserResponse {
string username = 1;
int32 age = 2;
bool gender = 3;
}

基于這個(gè)proto文件,可以生成客戶端和服務(wù)端的樁代碼。

在服務(wù)端,需要定義轉(zhuǎn)代碼中的handler接口。

在客戶端,可以通過(guò)樁代碼像調(diào)用本地函數(shù)一樣調(diào)用接口。

RPC API 的優(yōu)缺點(diǎn)

  1. 易于使用:RPC API通常提供了簡(jiǎn)單的接口,使得開發(fā)人員可以輕松地調(diào)用遠(yuǎn)程服務(wù),而無(wú)需關(guān)心底層通信和數(shù)據(jù)序列化的細(xì)節(jié)。
  2. 跨平臺(tái)兼容性:RPC API允許不同平臺(tái)和編程語(yǔ)言之間的通信,實(shí)現(xiàn)了代碼的復(fù)用和模塊化。
  3. 高性能:RPC API通常采用了高效的數(shù)據(jù)傳輸和通信機(jī)制,能夠提供較高的處理速度和響應(yīng)時(shí)間。
  1. 通信延遲:由于RPC API通常依賴于網(wǎng)絡(luò)通信,因此可能會(huì)受到網(wǎng)絡(luò)延遲和不穩(wěn)定的影響,從而導(dǎo)致較高的響應(yīng)時(shí)間和可用性風(fēng)險(xiǎn)。
  2. 安全性問(wèn)題:RPC API需要在網(wǎng)絡(luò)上傳輸敏感數(shù)據(jù),因此可能會(huì)受到網(wǎng)絡(luò)攻擊和數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
  3. 調(diào)試?yán)щy:當(dāng)RPC API調(diào)用出現(xiàn)問(wèn)題時(shí),調(diào)試可能會(huì)變得非常困難,因?yàn)殄e(cuò)誤信息可能分布在多個(gè)組件和服務(wù)中。

五、SOAP API

SOAP API 簡(jiǎn)介

SOAP(Simple Object Access Protocol,簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議)是一種基于 XML 的通信協(xié)議,它定義了用于 Web 上的應(yīng)用程序之間通信的標(biāo)準(zhǔn)格式。 SOAP API 是基于 SOAP 協(xié)議的一種 API 設(shè)計(jì)方式,用于實(shí)現(xiàn)應(yīng)用程序之間的數(shù)據(jù)交互和通信。

在 SOAP API 中,通信雙方都需要遵循一定的協(xié)議格式,以實(shí)現(xiàn)數(shù)據(jù)的傳遞和解析。SOAP API 由以下幾個(gè)關(guān)鍵概念組成:

  1. SOAP 消息:SOAP 消息是指基于 XML 的數(shù)據(jù)格式,用來(lái)在調(diào)用者和服務(wù)端之間傳遞信息。SOAP 消息包含 SOAP 頭(header)和 SOAP 體(body)兩個(gè)部分。
  2. SOAP 頭(Header):SOAP 頭是可選的,它用于傳遞一些用于處理消息的上下文信息,例如身份驗(yàn)證信息、編碼信息、事務(wù)處理信息等。
  3. SOAP 體(Body):SOAP 體是必需的,它包含了具體的方法調(diào)用和參數(shù)信息。
  4. SOAP 動(dòng)作(Action):SOAP 動(dòng)作定義了在 SOAP 消息中所包含方法的名稱。
  5. SOAP 協(xié)議綁定(Protocol Binding):SOAP 協(xié)議綁定定義了 SOAP 消息如何映射到底層傳輸協(xié)議(如 HTTP、SMTP、TCP、UDP等)。SOAP 協(xié)議綁定使得 SOAP 協(xié)議可以適配不同的傳輸協(xié)議。

SOAP API 的特點(diǎn)包括:

  1. 基于 XML:SOAP API 的數(shù)據(jù)格式基于 XML,使得數(shù)據(jù)交互具備更好的可讀性和可維護(hù)性。
  2. 統(tǒng)一標(biāo)準(zhǔn):SOAP API 定義了一套統(tǒng)一的標(biāo)準(zhǔn),使得應(yīng)用程序之間的通信更具有規(guī)范性和可互操作性。
  3. 支持多種傳輸協(xié)議: SOAP 協(xié)議綁定允許 SOAP API 適配大多數(shù)的底層傳輸協(xié)議,以滿足不同應(yīng)用層之間的交互需求。
  4. 廣泛應(yīng)用:SOAP API 作為一種通用的 API 設(shè)計(jì)規(guī)范,廣泛應(yīng)用于多個(gè)領(lǐng)域,例如企業(yè)集成、Web 服務(wù)、移動(dòng)應(yīng)用等。

SOAP API 示例

以下是一個(gè)基于 Amazon 的 Product Advertising API,使用 SOAP API 調(diào)用獲取某個(gè)關(guān)鍵詞的商品信息的示例。

SOAP 請(qǐng)求消息示例:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:api="http://soap.amazon.com">
<soapenv:Header/>
<soapenv:Body>
<api:ItemSearch>
<api:AssociateTag>Your_Associate_Tag</api:AssociateTag>
<api:Author>Stephen King</api:Author>
<api:Keywords>Carrie</api:Keywords>
<api:SearchIndex>Books</api:SearchIndex>
<api:ResponseGroup>Medium</api:ResponseGroup>
<api:Availability>Available</api:Availability>
<api:Sort>Title</api:Sort>
<api:Power><api:BrowseNode>17</api:BrowseNode>
</api:ItemSearch>
</soapenv:Body>
</soapenv:Envelope>

SOAP 相應(yīng)消息示例

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:api="http://soap.amazon.com">
<soapenv:Header/>
<soapenv:Body>
<api:ItemSearchResponse>
<api:Items>
<api:Request>
<api:ValidRequest>true</api:ValidRequest>
</api:Request>
<api:Item>
<api:ASIN>B0000ZD9PC</api:ASIN>
<api:DetailPageURL>http://www.amazon.com/Carrie-Stephen-King/dp/B0000ZD9PC</api:DetailPageURL>
<api:ItemAttributes>
<api:Title>Carrie: A Novel</api:Title>
<api:Author>Stephen King</api:Author>
<api:ListPrice>
<api:Amount>699</api:Amount>
<api:CurrencyCode>USD</api:CurrencyCode>
</api:ListPrice>
</api:ItemAttributes>
</api:Item>
</api:Items>
</api:ItemSearchResponse>
</soapenv:Body>
</soapenv:Envelope>

在上面的示例中,我們使用 ItemSearch 方法,向 Amazon 發(fā)送一個(gè)查詢關(guān)鍵詞“Carrie”的 SOAP 請(qǐng)求,并包含關(guān)鍵詞、搜索目錄、響應(yīng)類型、排序等參數(shù)。服務(wù)器返回查找結(jié)果,并在 SOAP 響應(yīng)消息中返回 Amazon 的商品信息。開發(fā)者可以按照 SOAP 響應(yīng)消息中的結(jié)構(gòu),解析并處理 Amazon 的商品信息。

SOAP API 優(yōu)缺點(diǎn)

  1. 安全性高:SOAP API 提供了諸如 WS-Security、HTTPS 等安全機(jī)制,提供了可靠、安全的通信。可在 SOAP 消息中包含簽名和加密,確保數(shù)據(jù)安全。
  2. 可擴(kuò)展性高:SOAP API 是基于 XML 標(biāo)準(zhǔn)設(shè)計(jì)的,SOAP 消息可以通過(guò) XML Schema 定義數(shù)據(jù)類型和結(jié)構(gòu),并支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和嵌套對(duì)象。
  3. 支持異構(gòu)平臺(tái):由于SOAP API使用通用的 XML 語(yǔ)言,所以支持跨不同的平臺(tái)、應(yīng)用程序和編程語(yǔ)言之間的數(shù)據(jù)傳輸和通信。
  1. 繁瑣的數(shù)據(jù)格式: SOAP API 能夠處理XML的復(fù)雜性和強(qiáng)大的擴(kuò)展性使其變得非常繁瑣。
  2. 性能比 RESTful API 低:SOAP API 要求數(shù)據(jù)格式必須為 XML,相較于 JSON 格式的 RESTful API,數(shù)據(jù)量會(huì)比較大,且該格式要求的數(shù)據(jù)解析和序列化會(huì)更加耗時(shí)。
  3. 需要更復(fù)雜協(xié)議:SOAP 協(xié)議需要使用許多的協(xié)議層,如 HTTP、XML、SOAP、WSDL 等,以確保協(xié)議可靠,也需要更多的開發(fā)時(shí)間和經(jīng)驗(yàn)。所以在 API 技術(shù)選擇時(shí)不建議考慮 SOAP API,因?yàn)槭褂?SOAP 的開銷非常大,特別是在資源有限的系統(tǒng)上。

六、對(duì)比分析

下表列出了四種主流的API風(fēng)格在使用場(chǎng)景、數(shù)據(jù)格式和接口性能等方面的比較:

API風(fēng)格使用場(chǎng)景數(shù)據(jù)格式接口性能
SOAP API企業(yè)級(jí)應(yīng)用、大規(guī)模數(shù)據(jù)請(qǐng)求與查詢、跨平臺(tái)應(yīng)用XML
RESTful API互聯(lián)網(wǎng)Web應(yīng)用、處理實(shí)時(shí)數(shù)據(jù)、與前端結(jié)合JSON/XML
GraphQL需要控制返回的數(shù)據(jù)字段、精細(xì)定制查詢自定義查詢語(yǔ)言
gRPC對(duì)內(nèi)應(yīng)用程序、處理大量數(shù)據(jù)傳輸請(qǐng)求protobufs

本文章轉(zhuǎn)載微信公眾號(hào)@Tech Lead 進(jìn)階

上一篇:

掌握 API 生命周期:基本階段和行之有效的成功策略

下一篇:

實(shí)用 Web API 規(guī)范
#你可能也喜歡這些API文章!

我們有何不同?

API服務(wù)商零注冊(cè)

多API并行試用

數(shù)據(jù)驅(qū)動(dòng)選型,提升決策效率

查看全部API→
??

熱門場(chǎng)景實(shí)測(cè),選對(duì)API

#AI文本生成大模型API

對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力

25個(gè)渠道
一鍵對(duì)比試用API 限時(shí)免費(fèi)

#AI深度推理大模型API

對(duì)比大模型API的邏輯推理準(zhǔn)確性、分析深度、可視化建議合理性

10個(gè)渠道
一鍵對(duì)比試用API 限時(shí)免費(fèi)