API 架構(gòu)選哪種？SOAP、REST、GraphQL 與 RPC 全方位對比分析

作者：架構(gòu)精進(jìn)之路 2025-10-31 01:15:00

本文討論了四種主要的 API 架構(gòu)風(fēng)格，比較它們的優(yōu)缺點(diǎn)，并重點(diǎn)介紹每種情況下最適合的 API 架構(gòu)風(fēng)格。

兩個單獨(dú)的應(yīng)用程序需要中介程序才能相互通信。因此，開發(fā)人員經(jīng)常需要搭建橋梁——也就是應(yīng)用程序編程接口（API），來允許一個系統(tǒng)訪問另一個系統(tǒng)的信息或功能。

為了快速、大規(guī)模地集成不同的應(yīng)用程序，API 使用協(xié)議或規(guī)范來定義那些通過網(wǎng)絡(luò)傳輸?shù)南⒌恼Z義和信息。這些規(guī)范構(gòu)成了 API 的體系結(jié)構(gòu)。

在過去，人們已經(jīng)發(fā)布了多種不同的 API 架構(gòu)風(fēng)格。每個架構(gòu)風(fēng)格都有它獨(dú)有的標(biāo)準(zhǔn)化數(shù)據(jù)交換的模式。這一系列的 API 架構(gòu)風(fēng)格的選項(xiàng)，引發(fā)了大量的關(guān)于哪種架構(gòu)風(fēng)格才是最好的爭論。

不同時間的 API 架構(gòu)風(fēng)格，圖源：Rob Crowley

今天，許多 API 的使用者將 REST 稱作“消亡的 REST”（REST in peace），并且為 GraphQL 感到歡欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的贏家。這些觀點(diǎn)的問題在于，它們的出發(fā)點(diǎn)只是為某種技術(shù)背書，而不是去考慮它實(shí)際的屬性和特性如何與當(dāng)前的需求相匹配。

四種 API 架構(gòu)風(fēng)格

1.RPC：調(diào)用另一個系統(tǒng)的函數(shù)

遠(yuǎn)程過程調(diào)用是一種允許在不同上下文中遠(yuǎn)程執(zhí)行函數(shù)的規(guī)范。RPC 擴(kuò)展了本地過程調(diào)用的概念，并將其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在問題的，因?yàn)楹茈y確保 XML 有效負(fù)載的數(shù)據(jù)類型。因此，后來 RPC API 開始使用一個更具體的 JSON-RPC 規(guī)范，該規(guī)范被認(rèn)為是 SOAP 的更簡單的替代方案。gRPC 是 Google 在 2015 年開發(fā)的最新 RPC 版本。gRPC 可插拔支持負(fù)載均衡、追蹤、運(yùn)行狀況檢查和身份驗(yàn)證，它非常適合連接不同的微服務(wù)。

RPC 的工作機(jī)制

客戶端調(diào)用一個遠(yuǎn)程的過程，將參數(shù)和附加信息序列化為消息，然后將消息發(fā)送到服務(wù)端。服務(wù)端在接受到消息后，將信息的內(nèi)容反序列化，執(zhí)行所請求的操作，然后將結(jié)果發(fā)送回客戶端。客戶端和服務(wù)端各自負(fù)責(zé)參數(shù)的序列化和反序列化。

遠(yuǎn)程過程調(diào)用的機(jī)制，圖源：Guru99

RPC 的優(yōu)勢

簡單直接的交互。RPC 使用 GET 來獲取信息，使用 POST 來處理其他所有操作。服務(wù)端和客戶端之間交互的機(jī)制歸結(jié)為調(diào)用端點(diǎn)并獲得響應(yīng)。

易于添加新函數(shù)。 如果 API 有了新的需求，我們可以輕松地添加另一個執(zhí)行這個需求的端點(diǎn)：1）編寫一個新函數(shù)，并將其放在一個新端點(diǎn)之后；2）現(xiàn)在，客戶可以訪問這個端點(diǎn)，并獲取符合其需求的信息。

高性能。輕量級的有效負(fù)載不會對網(wǎng)絡(luò)產(chǎn)生壓力，以此提供高性能，這對于共享服務(wù)器和在工作站網(wǎng)絡(luò)上執(zhí)行并行計(jì)算非常重要。RPC 還能夠優(yōu)化網(wǎng)絡(luò)層，使得不同服務(wù)之間每天發(fā)送海量消息變得非常高效。

RPC 的不足

和底層系統(tǒng)緊密耦合。API 的抽象級別有助于其可重用性。API 與基礎(chǔ)系統(tǒng)的耦合越緊密，對其他系統(tǒng)的可重用性就越差。RPC 與基礎(chǔ)系統(tǒng)的緊密耦合不允許其在系統(tǒng)函數(shù)和外部 API 之間建立抽象層。這很容易引起安全問題，因?yàn)殛P(guān)于基礎(chǔ)系統(tǒng)的細(xì)節(jié)實(shí)現(xiàn)很容易會泄漏到 API 中。

RPC 的緊密耦合使得可伸縮性要求和松散耦合的團(tuán)隊(duì)難以實(shí)現(xiàn)。因此，客戶端要么會擔(dān)心調(diào)用特定端點(diǎn)的帶來的任何可能的副作用，要么需要嘗試弄清楚要調(diào)用的端點(diǎn)，因?yàn)榭蛻舳瞬涣私夥?wù)器如何命名其函數(shù)。

可發(fā)現(xiàn)性低。 在 RPC 中，無法對 API 進(jìn)行檢驗(yàn)總結(jié)，或者發(fā)送請求來開始理解根據(jù)需求應(yīng)該調(diào)用哪個函數(shù)。

函數(shù)爆炸性增長。創(chuàng)建新函數(shù)非常容易。因此，相較于重新編輯現(xiàn)有的函數(shù)，我們會傾向于創(chuàng)建新的功能，最終產(chǎn)生大量難以理解的、功能重疊的函數(shù)。

RPC 的用例

RPC 模式在八十年代開始使用，但這并不意味著它已經(jīng)過時了。諸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）這樣的大公司如今正在內(nèi)部使用高性能的 RPC 版本，來執(zhí)行極高性能、低開銷的消息傳遞。它們龐大的微服務(wù)系統(tǒng)要求內(nèi)部通信在使用短消息的情況下也保持清晰。

命令 API。RPC 是用于將命令發(fā)送到遠(yuǎn)程系統(tǒng)的正確選擇。例如，Slack API 是非常以命令為中心的：加入頻道、離開頻道、發(fā)送消息。因此，Slack API 的設(shè)計(jì)者以類似于 RPC 的樣式對其進(jìn)行了建模，使其小巧、緊湊并且易于使用。

用于內(nèi)部微服務(wù)的客戶特定的 API。由于是在單個提供者和單個使用者之間建立直接的集成，我們不想像 REST API 那樣，花太多時間通過網(wǎng)絡(luò)傳輸大量的元數(shù)據(jù)。憑借高消息速率和消息性能，gRPC 和 Twirp 成為了用于微服務(wù)的可靠用例。通過在底層使用 HTTP 2，gRPC 能優(yōu)化網(wǎng)絡(luò)層，使其非常高效地在不同服務(wù)之間每天傳送大量信息。然而，如果你并不是要著眼于提高網(wǎng)絡(luò)性能，而是要在發(fā)布高度獨(dú)立的微服務(wù)團(tuán)隊(duì)之間建立一個穩(wěn)定的 API 聯(lián)系。REST 就能做到。

2.SOAP：使數(shù)據(jù)作為服務(wù)可用

SOAP 是一個 XML 格式的、高度標(biāo)準(zhǔn)化的網(wǎng)絡(luò)通訊協(xié)議。在 XML-RPC 發(fā)布的一年后，SOAP 由微軟發(fā)布、并繼承了許多 XML-RPC 的特性。在 REST 緊隨其后發(fā)布，一開始它們是被同時使用，但很快 REST 贏得了這次比賽，成為了更流行的協(xié)議。

SOAP 的工作機(jī)制

XML 數(shù)據(jù)格式拖累了很多數(shù)據(jù)規(guī)范。伴隨著大量的消息結(jié)構(gòu)，XML 數(shù)據(jù)格式使得 SOAP 成為了最冗長的 API 架構(gòu)風(fēng)格。

SOAP 的消息由這些部件組成：

一個信封標(biāo)簽：用于開始和結(jié)束每條消息
包含請求或響應(yīng)的正文
一個標(biāo)頭：用于表示消息是否由某些規(guī)范或額外要求的來確認(rèn)
故障通知：包含了可能在請求處理過程只能夠發(fā)生的任何錯誤

一個 SOAP 消息的例子，圖源：IBM

SOAP API 的邏輯由 Web 服務(wù)描述語言（WSDL）編寫。該 API 描述語言定義了端點(diǎn)并描述了可以執(zhí)行的所有過程。這使得不同的編程語言和 IDE 能夠快速建立通信。

SOAP 支持有狀態(tài)和無狀態(tài)消息傳遞。在有狀態(tài)的情況下，服務(wù)器存儲接收到的信息可能非常繁瑣復(fù)雜。但這對于涉及多方和復(fù)雜交易的操作是合理的。

SOAP 的優(yōu)勢

獨(dú)立于語言和平臺。內(nèi)置創(chuàng)建 Web 服務(wù)的功能使得 SOAP 能夠處理消息通信的同時發(fā)送獨(dú)立于語言和平臺響應(yīng)。

綁定到各種協(xié)議。SOAP 在適用于多種場景的傳輸協(xié)議方面是十分靈活的。

內(nèi)置錯誤處理。SOAP API 規(guī)范允許返回帶有錯誤碼及其說明的的 XML 重試消息。

一系列的安全拓展。SOAP 與 ES-Security 集成，因此 SOAP 可滿足企業(yè)級事務(wù)要求。它在事務(wù)內(nèi)部提供了隱私和完整性，同時允許在消息級別進(jìn)行加密。

SOAP 消息級別的安全性：在標(biāo)頭元素的認(rèn)證數(shù)據(jù)以及加密的正文

SOAP 的不足

如今，由于如下幾種原因，許多開發(fā)人員在聽到必須集成 SOAP API 的想法后都會感到不安。

僅使用 XML。SOAP 消息包含大量的元數(shù)據(jù)，并且在請求和響應(yīng)時僅支持繁冗的 XML 格式。

重量級。由于 XML 文件的大小，SOAP 服務(wù)需要很大的帶寬。

非常專業(yè)化的知識。構(gòu)建 SOAP API 服務(wù)器需要對所有涉及到的協(xié)議以及它們及其嚴(yán)格的限制都有很深的了解。

乏味的消息更新。由于需要額外的工作來添加或者刪除某個消息屬性，這種死板的 SOAP 模式減慢了其被采用的速度。

SOAP 的用例

目前，SOAP 體系結(jié)構(gòu)最常用于企業(yè)內(nèi)部或與其信任的合作伙伴的內(nèi)部集成。

高度安全的數(shù)據(jù)傳輸。SOAP 嚴(yán)格的消息結(jié)構(gòu)，安全性和授權(quán)功能使其成為在 API 和客戶端之間執(zhí)行正式軟件協(xié)議的最合適的選擇，同時又符合 API 提供者與 API 使用者之間的法律合同。這就是為什么金融組織和其他企業(yè)用戶選擇適用 SOAP 的原因。

3.REST：使數(shù)據(jù)作為資源可用

REST 如今是一種無需解釋的 API 架構(gòu)風(fēng)格，它由一系列的架構(gòu)約束所定義，旨在被廣泛 API 使用者采用。

當(dāng)前最常見的 API 架構(gòu)風(fēng)格最初時由 Roy Fielding 在其博士論文中提出的。REST 使得服務(wù)端的數(shù)據(jù)可用，并以簡單的格式（通常是 JSON 和 XML）來表示它。

REST 的工作機(jī)制

REST 的定義并不像 SOAP 那樣嚴(yán)格。RESTful 體系結(jié)構(gòu)應(yīng)該遵守如下六個體系結(jié)構(gòu)約束：

統(tǒng)一接口：無論設(shè)備或應(yīng)用程序類型如何，都可以采用統(tǒng)一的方式與給定的服務(wù)端進(jìn)行交互。
無狀態(tài)：請求本身包含處理該請求所需要的狀態(tài)，并且服務(wù)端不存儲與會話相關(guān)的任何內(nèi)容。
緩存
客戶端 - 服務(wù)器體系結(jié)構(gòu)：允許雙方獨(dú)立發(fā)展
應(yīng)用程序的層級系統(tǒng)
服務(wù)端向客戶端提供可執(zhí)行代碼的能力

實(shí)際上，某些服務(wù)僅在某種程度上是 RESTful 的。而它們的內(nèi)核采用了 RPC 樣式，將較大的服務(wù)分解為資源，并有效地使用 HTTP 基礎(chǔ)結(jié)構(gòu)。但 REST 的關(guān)鍵部分是超媒體（又稱 HATEOAS），是超文本作為應(yīng)用程序狀態(tài)引擎（Hypertext As The Enginer Of Application State）的縮寫。基本來說，這意味著 REST API 在每個響應(yīng)中都提供元數(shù)據(jù)，該元數(shù)據(jù)鏈接了有關(guān)如何使用該 API 的所有相關(guān)信息。這樣便可以使客戶端和服務(wù)端解耦。因此，API 提供者和 API 使用者都可以獨(dú)立發(fā)展，而這并不會阻礙他們的交流。

理查森成熟度模型作為實(shí)現(xiàn)真正完整且有用的 API 架構(gòu)的目標(biāo)。圖源：Kristopher Sando

“HATEOAS 才是 REST 的關(guān)鍵功能，因?yàn)樗嬲沟?REST 成為 REST。但由于大多數(shù)人不使用 HATEOAS，因此他們實(shí)際上是在使用 HTTP RPC。”這是 Reddit 上表達(dá)的一些激進(jìn)觀點(diǎn)。確實(shí)，HATEOAS 是 REST 的最成熟版本。

但是，這非常難以實(shí)現(xiàn)，因?yàn)檫@要求 API 客戶端要比它們?nèi)缃駱?gòu)建和使用的方式變得更先進(jìn)和智能得多。因此，即便是如今非常好的 REST API 也不一定總是能做到這一點(diǎn)。這就是為什么 HATEOAS 主要是作為 RESTful API 設(shè)計(jì)的長期開發(fā)的愿景而存在。

當(dāng)服務(wù)端實(shí)現(xiàn) REST 的某些功能和 RPC 的某些功能時，在 REST 和 RPC 之間確實(shí)可能存在這樣一個灰色區(qū)域。但 REST 是基于資源或名詞的，而不是基于動作或動詞。

以動詞為中心的 RPC 模型和以名詞為中心的 REST 模型中的操作對比

在 REST 中，使用例如 GET、POST、PUT、DELETE、OPTIONS 可能還有 PATCH 等 HTTP 方法來完成操作。

圖源：Thomas David

REST 的優(yōu)勢

客戶端和服務(wù)端的解耦：由于 REST 盡可能地解耦了客戶端和服務(wù)端，REST 相較于 RPC 可以提供更好的抽象性。具有抽象級別的系統(tǒng)能夠封裝其實(shí)現(xiàn)細(xì)節(jié)，以更好的標(biāo)示和維持它的屬性。這使得 REST API 足夠靈活，可以隨著時間的推移而發(fā)展，同時保持穩(wěn)定的系統(tǒng)。

可發(fā)現(xiàn)性：客戶端和服務(wù)端之間的通信描述了所有內(nèi)容，因此不需要外部文檔即可了解如何與 REST API 進(jìn)行交互。

緩存友好：REST 重用了許多 HTTP 工具，也是唯一一種可以在 HTTP 層面上緩存數(shù)據(jù)的 API 架構(gòu)風(fēng)格。與其相對的是，在任何其他 API 上實(shí)現(xiàn)緩存都需要配置其他緩存模塊。

多種格式支持：REST 擁有支持多種格式用于存儲和交換數(shù)據(jù)的能力，這是它如今成為搭建公共 API 的主要選擇的原因之一。

REST 的不足

沒有標(biāo)準(zhǔn)的 REST 結(jié)構(gòu)：在構(gòu)建 REST API 方面，沒有具體的正確方法。如何對資源進(jìn)行建模以及哪些資源需要建模取決于不同的情況。這使得 REST 在理論上很簡單，但在實(shí)踐中卻很困難。

龐大的負(fù)載：REST 會返回大量豐富的元數(shù)據(jù)，以便客戶端可以僅從響應(yīng)中了解有關(guān)應(yīng)用程序狀態(tài)的所有必要信息。對于具有大量帶寬容量的大型網(wǎng)絡(luò)系統(tǒng)來說，這種“啰嗦”的通信并不算很大的負(fù)載。但帶寬容量并非總是足夠的。這也是 Facebook 在 2012 年提出 GraphQL 架構(gòu)風(fēng)格的關(guān)鍵驅(qū)動因素。

響應(yīng)過度和響應(yīng)不足問題。REST 的響應(yīng)包含的數(shù)據(jù)會過多或不足，通常會導(dǎo)致客戶端需要發(fā)送另一個請求。

REST 的用例

管理 API。在系統(tǒng)中，專注于管理對象并面向許多使用者的 API 是最常見的 API 類型。REST 幫助此類 API 具有強(qiáng)大的可發(fā)現(xiàn)性，良好的文檔編制，因此 REST 非常適合此對象模型。

簡單的資源驅(qū)動型應(yīng)用程序。在用于連接不需要查詢靈活性的資源驅(qū)動型應(yīng)用時，REST 是一種非常有效的方法。

4.GraphQL：僅請求所需要的數(shù)據(jù)

REST API 需要被多次調(diào)用才能返回所需要的資源。所以，GraphQL 被發(fā)明了，并改變了這一切游戲的規(guī)則。

GraphQL 是一種語法，它描述了如何進(jìn)行精確的數(shù)據(jù)請求。有些應(yīng)用程序的數(shù)據(jù)模型具有許多相互引用的復(fù)雜實(shí)體，在這種情況下，實(shí)現(xiàn) GraphQL 是值得的。

如何從 GraphQL 端點(diǎn)僅獲取所需要的數(shù)據(jù)，圖源：Mohit Tikoo

如今，GraphQL 的生態(tài)系統(tǒng)正在蓬勃發(fā)展，出現(xiàn)了例如 Apollo、GraphiQL 和 GraphQL Explorer 等強(qiáng)大的庫和工具。

GraphQL 的工作機(jī)制

GraphQL 從構(gòu)建模式（Schema）開始。模式是對于用戶可以在 GraphQL API 中進(jìn)行的所有查詢及其返回的所有類型的描述。模式構(gòu)建非常困難，因?yàn)樗枰褂媚Ｊ蕉x語言（SDL）進(jìn)行強(qiáng)類型化。

因?yàn)樵诳蛻舳诉M(jìn)行查詢之前已經(jīng)定義好了模式，所以客戶端可以驗(yàn)證其查詢語句，以確保服務(wù)端能夠?qū)Σ樵冋Z句進(jìn)行響應(yīng)。在查詢語句到達(dá)后端應(yīng)用程序時，GraphQL 操作將根據(jù)整個模式進(jìn)行解釋，并向前端應(yīng)用程序返回解析到的數(shù)據(jù)。API 向服務(wù)端發(fā)送一個龐大的查詢，該 API 返回一個僅包含我們所需數(shù)據(jù)的 JSON 響應(yīng)。

GraphQL 的查詢語句執(zhí)行，圖源：Jonas Helfer

除了包含 RESTful 的 CRUD 操作，GraphQL 還有訂閱（subscriptions）機(jī)制，允許接收來自服務(wù)端的實(shí)時通知。

GraphQL 的優(yōu)勢

具有類型的模式：GraphQL 提前公開了它能做什么，從而提高了其可發(fā)現(xiàn)性。通過將客戶端指向 GraphQL API，我們可以發(fā)現(xiàn)什么查詢語句是可用的。

沒有版本控制：版本控制的最佳實(shí)踐是不要對 API 進(jìn)行版本控制。

盡管 REST 提供了不同的 API 版本，GraphQL 使用的是不斷更新的單一版本，這使用戶可以持續(xù)訪問新功能，并有助于提供更整潔、更可維護(hù)的服務(wù)器代碼。

詳細(xì)的錯誤消息：GraphQL 以類似于 SOAP 的方式提供所發(fā)生錯誤的詳細(xì)信息。它的錯誤消息包括所有解析器，并指向確切的發(fā)生故障時的查詢部分。

靈活的權(quán)限：GraphQL 允許選擇性地公開某些功能，同時保留私人信息。而相對應(yīng)的是，REST 體系架構(gòu)不能僅顯示部分?jǐn)?shù)據(jù)，要么是全部數(shù)據(jù)，要么是沒有數(shù)據(jù)。

GraphQL 的不足

性能問題。GraphQL 權(quán)衡了復(fù)雜性，來實(shí)現(xiàn)其強(qiáng)大功能。一個請求中的嵌套字段太多會導(dǎo)致系統(tǒng)過載。因此，對于復(fù)雜的查詢，REST 仍然是更好的選擇。

緩存復(fù)雜度。由于 GraphQL 不再使用 HTTP 緩存語義，因此使用者需要額外自定義緩存。

大量的預(yù)開發(fā)教育。由于沒有足夠的時間來了解 GraphQL 的某個操作和 SDL，因此許多項(xiàng)目決定采用眾所周知的 REST 方法。

GraphQL 的用例

移動 API。在這種情況下，網(wǎng)絡(luò)性能和單個消息有效負(fù)載優(yōu)化很重要。因此，GraphQL 為移動設(shè)備提供了更有效的數(shù)據(jù)加載方式。

復(fù)雜的系統(tǒng)和微服務(wù)。GraphQL 能夠隱藏其 API 背后的多個系統(tǒng)集成的復(fù)雜性。GraphQL 從多個地方聚合數(shù)據(jù)，并將它們合并為一個全局的模式。對于隨時間推移而逐漸擴(kuò)展的遺留基礎(chǔ)架構(gòu)或第三方 API 來說，這尤其重要。