四種 API 架構風格

掃碼關註 「 後端架構師 」，選擇 「 星標 」 公眾號

重磅幹貨，第一時間送達！

責編：架構君 | 作者：AltexSoft Inc

原文：https://blog.zhangbing.site/2020/12/13/comparing-api-architectural- styles-soap-vs-rest-vs-graphql-vs-rpc/

來源：https://levelup.gitconnected.com/comparing-api-architectural- styles-soap-vs-rest-vs-graphql-vs-rpc-84a3720adefa

上一篇好文：

大家好，我是後端架構師。

本文我們來討論四種主要的 API 架構風格，比較它們的優缺點，並重點介紹每種情況下最適合的 API 架構風格。

兩個單獨的應用程式需要中介程式才能相互通訊，因此，開發人員經常需要搭建橋梁——也就是 應用程式編程介面 （API），來允許一個系統存取另一個系統的資訊或功能。

為了快速、大規模地整合不同的應用程式，API 使用協定或規範來定義那些透過網路傳輸的訊息的語意和資訊。這些規範構成了 API 的體系結構。

在過去，人們已經釋出了多種不同的 API 架構風格。每個架構風格都有它獨有的標準化數據交換的模式。這一系列的 API 架構風格的選項，引發了大量的關於哪種架構風格才是最好的爭論。

今天，許多 API 的使用者將 REST 稱作「消亡的 REST」（REST in peace），並且為 GraphQL 感到歡欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的贏家。這些觀點的問題在於，它們的出發點只是為某種技術背書，而不是去考慮它實際的內容和特性如何與當前的需求相匹配。

RPC：呼叫另一個系統的函式

遠端程序呼叫是一種允許在不同上下文中遠端執行函式的規範。RPC 擴充套件了本地過程呼叫的概念，並將其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在問題的，因為很難確保 XML 有效負載的數據型別。因此，後來 RPC API 開始使用一個更具體的 JSON-RPC 規範，該規範被認為是 SOAP 的更簡單的替代方案。gRPC 是 Google 在 2015 年開發的最新 RPC 版本。gRPC 可插拔支持負載均衡、追蹤、執行狀況檢查和身份驗證，它非常適合連線不同的微服務。

RPC 的工作機制

客戶端呼叫一個遠端的過程，將參數和附加資訊序列化為訊息，然後將訊息發送到伺服端。伺服端在接受到訊息後，將資訊的內容反序列化，執行所請求的操作，然後將結果發送回客戶端。客戶端和伺服端各自負責參數的序列化和反序列化。

RPC 的優勢

簡單直接的互動。 RPC 使用 GET 來獲取資訊，使用 POST 來處理其他所有操作。伺服端和客戶端之間互動的機制歸結為呼叫端點並獲得響應。

易於添加新函式。 如果 API 有了新的需求，我們可以輕松地添加另一個執行這個需求的端點：1）編寫一個新函式，並將其放在一個新端點之後；2）現在，客戶可以存取這個端點，並獲取符合其需求的資訊。

高效能 。輕量級的有效負載不會對網路產生壓力，以此提供高效能，這對於共享伺服器和在工作站網路上執行平行計算非常重要。RPC 還能夠最佳化網路層，使得不同服務之間每天發送海量訊息變得非常高效。

RPC 的不足

和底層系統緊密耦合。 API 的抽象級別有助於其可重用性。API 與基礎系統的耦合越緊密，對其他系統的可重用性就越差。RPC 與基礎系統的緊密耦合不允許其在系統函式和外部 API 之間建立抽象層。這很容易引起安全問題，因為關於基礎系統的細節實作很容易會泄漏到 API 中。

RPC 的緊密耦合使得可伸縮性要求和松散耦合的團隊難以實作。因此，客戶端要麽會擔心呼叫特定端點的帶來的任何可能的副作用，要麽需要嘗試弄清楚要呼叫的端點，因為客戶端不了解伺服器如何命名其函式。

可發現性低。 在 RPC 中，無法對 API 進行檢驗總結，或者發送請求來開始理解根據需求應該呼叫哪個函式。

函式爆炸性增長 。建立新函式非常容易。因此，相較於重新編輯現有的函式，我們會傾向於建立新的功能，最終產生大量難以理解的、功能重疊的函式。

RPC 的用例

RPC 模式在八十年代開始使用，但這並不意味著它已經過時了。諸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）這樣的大公司如今正在內部使用高效能的 RPC 版本，來執行極高效能、低開銷的訊息傳遞。它們龐大的微服務系統要求內部通訊在使用短訊息的情況下也保持清晰。

命令 API 。RPC 是用於將命令發送到遠端系統的正確選擇。例如，Slack API 是非常以命令為中心的：加入頻道、離開頻道、發送訊息。因此，Slack API 的設計者以類似於 RPC 的樣式對其進行了建模，使其小巧、緊湊並且易於使用。

用於內部微服務的客戶特定的 API 。由於是在單個提供者和單個使用者之間建立直接的整合，我們不想像 REST API 那樣，花太多時間透過網路傳輸大量的後設資料。憑借高訊息速率和訊息效能，gRPC 和 Twirp 成為了用於微服務的可靠用例。透過在底層使用 HTTP 2，gRPC 能最佳化網路層，使其非常高效地在不同服務之間每天傳送大量資訊。然而，如果你並不是要著眼於提高網路效能，而是要在釋出高度獨立的微服務團隊之間建立一個穩定的 API 聯系。REST 就能做到。

SOAP：使數據作為服務可用

SOAP 是一個 XML 格式的、高度標準化的網路通訊協定。在 XML-RPC 釋出的一年後，SOAP 由微軟釋出、並繼承了許多 XML-RPC 的特性。在 REST 緊隨其後釋出，一開始它們是被同時使用，但很快 REST 贏得了這次比賽，成為了更流行的協定。

SOAP 的工作機制

XML 數據格式拖累了很多數據規範。伴隨著大量的訊息結構，XML 數據格式使得 SOAP 成為了最冗長的 API 架構風格。

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

SOAP API 的邏輯由 Web 服務描述語言（ WSDL ）編寫。該 API 描述語言定義了端點並描述了可以執行的所有過程。這使得不同的程式語言和 IDE 能夠快速建立通訊。

SOAP 支持有狀態和無狀態訊息傳遞。在有狀態的情況下，伺服器儲存接收到的資訊可能非常繁瑣復雜。但這對於涉及多方和復雜交易的操作是合理的。

SOAP 的優勢

獨立於語言和平台 。內建建立 Web 服務的功能使得 SOAP 能夠處理訊息通訊的同時發送獨立於語言和平台響應。

繫結到各種協定 。SOAP 在適用於多種場景的傳輸協定方面是十分靈活的。

內建錯誤處理 。SOAP API 規範允許返回帶有錯誤碼及其說明的的 XML 重試訊息。

一系列的安全拓展 。SOAP 與 ES-Security 整合，因此 SOAP 可滿足企業級事務要求。它在事務內部提供了私密和完整性，同時允許在訊息級別進行加密。

SOAP 的不足

如今，由於如下幾種原因，許多開發人員在聽到必須整合 SOAP API 的想法後都會感到不安。

僅使用 XML 。SOAP 訊息包含大量的後設資料，並且在請求和響應時僅支持繁冗的 XML 格式。

重量級 。由於 XML 檔的大小，SOAP 服務需要很大的頻寬。

非常專業化的知識 。構建 SOAP API 伺服器需要對所有涉及到的協定以及它們及其嚴格的限制都有很深的了解。

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

SOAP 的用例

目前，SOAP 體系結構最常用於企業內部或與其信任的合作夥伴的內部整合。

高度安全的數據傳輸 。SOAP 嚴格的訊息結構，安全性和授權功能使其成為在 API 和客戶端之間執行正式軟體協定的最合適的選擇，同時又符合 API 提供者與 API 使用者之間的法律合約。這就是為什麽金融組織和其他企業使用者選擇適用 SOAP 的原因。

REST：使數據作為資源可用

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

當前最常見的 API 架構風格最初時由 Roy Fielding 在其博士論文中提出的。REST 使得伺服端的數據可用，並以簡單的格式（通常是 JSON 和 XML）來表示它。

REST 的工作機制

REST 的定義並不像 SOAP 那樣嚴格。RESTful 體系結構應該遵守如下六個體系結構約束：

實際上，某些服務僅在某種程度上是 RESTful 的。而它們的內核采用了 RPC 樣式，將較大的服務分解為資源，並有效地使用 HTTP 基礎結構。但 REST 的關鍵部份是超媒體（又稱 HATEOAS），是 超文本 作為應用程式狀態引擎（Hypertext As The Enginer Of Application State）的縮寫。基本來說，這意味著 REST API 在每個響應中都提供後設資料，該後設資料連結了有關如何使用該 API 的所有相關資訊。這樣便可以使客戶端和伺服端解耦。因此，API 提供者和 API 使用者都可以獨立發展，而這並不會阻礙他們的交流。

「HATEOAS 才是 REST 的關鍵功能，因為它真正使得 REST 成為 REST。但由於大多數人不使用 HATEOAS，因此他們實際上是在使用 HTTP RPC。」這是 Reddit 上表達的一些激進觀點。確實，HATEOAS 是 REST 的最成熟版本。

但是，這非常難以實作，因為這要求 API 客戶端要比它們如今構建和使用的方式變得更先進和智慧得多。因此，即便是如今非常好的 REST API 也不一定總是能做到這一點。這就是為什麽 HATEOAS 主要是作為 RESTful API 設計的長期開發的願景而存在。

當伺服端實作 REST 的某些功能和 RPC 的某些功能時，在 REST 和 RPC 之間確實可能存在這樣一個灰色區域。但 REST 是基於資源或名詞的，而不是基於動作或動詞。

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

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

REST 的優勢

客戶端和伺服端的解耦 ：由於 REST 盡可能地解耦了客戶端和伺服端，REST 相較於 RPC 可以提供更好的抽象性。具有抽象級別的系統能夠封裝其實作細節，以更好的標示和維持它的內容。這使得 REST API 足夠靈活，可以隨著時間的推移而發展，同時保持穩定的系統。

可發現性 ：客戶端和伺服端之間的通訊描述了所有內容，因此不需要外部文件即可了解如何與 REST API 進行互動。

緩存友好 ：REST 重用了許多 HTTP 工具，也是唯一一種可以在 HTTP 層面上緩存數據的 API 架構風格。與其相對的是，在任何其他 API 上實作緩存都需要配置其他緩存模組。

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

REST 的不足

沒有標準的 REST 結構 ：在構建 REST API 方面，沒有具體的正確方法。如何對資源進行建模以及哪些資源需要建模取決於不同的情況。這使得 REST 在理論上很簡單，但在實踐中卻很困難。

龐大的負載： REST 會返回大量豐富的後設資料，以便客戶端可以僅從響應中了解有關應用程式狀態的所有必要資訊。對於具有大量頻寬容量的大型網路系統來說，這種「啰嗦」的通訊並不算很大的負載。但頻寬容量並非總是足夠的。這也是 Facebook 在 2012 年提出 GraphQL 架構風格的關鍵驅動因素。

響應過度和響應不足問題 。REST 的響應包含的數據會過多或不足，通常會導致客戶端需要發送另一個請求。

REST 的用例

管理 API 。在系統中，專註於管理物件並面向許多使用者的 API 是最常見的 API 型別。REST 幫助此類 API 具有強大的可發現性，良好的文件編制，因此 REST 非常適合此物件模型。

簡單的資源驅動型應用程式 。在用於連線不需要查詢靈活性的資源驅動型套用時，REST 是一種非常有效的方法。

GraphQL：僅請求所需要的數據

REST API 需要被多次呼叫才能返回所需要的資源。所以，GraphQL 被發明了，並改變了這一切遊戲的規則。

GraphQL 是一種語法，它描述了如何進行精確的數據請求。有些應用程式的數據模型具有許多相互參照的復雜實體，在這種情況下，實作 GraphQL 是值得的。

如今，GraphQL 的生態系正在蓬勃發展，出現了例如 Apollo、GraphiQL 和 GraphQL Explorer 等強大的庫和工具。

GraphQL 的工作機制

GraphQL 從構建模式（Schema）開始。模式是對於使用者可以在 GraphQL API 中進行的所有查詢及其返回的所有型別的描述。模式構建非常困難，因為它需要使用模式定義語言（SDL）進行強型別化。

因為在客戶端進行查詢之前已經定義好了模式，所以客戶端可以驗證其查詢語句，以確保伺服端能夠對查詢語句進行響應。在查詢語句到達後端應用程式時，GraphQL 操作將根據整個模式進行解釋，並向前端應用程式返回解析到的數據。API 向伺服端發送一個龐大的查詢，該 API 返回一個僅包含我們所需數據的 JSON 響應。

除了包含 RESTful 的 CRUD 操作，GraphQL 還有訂閱（subscriptions）機制，允許接收來自伺服端的即時通知。

GraphQL 的優勢

具有型別的模式 ：GraphQL 提前公開了它能做什麽，從而提高了其可發現性。透過將客戶端指向 GraphQL API，我們可以發現什麽查詢語句是可用的。

沒有版本控制 ：版本控制的最佳實踐是不要對 API 進行版本控制。

盡管 REST 提供了不同的 API 版本，GraphQL 使用的是不斷更新的單一版本，這使使用者可以持續存取新功能，並有助於提供更整潔、更可維護的伺服器程式碼。

詳細的錯誤訊息 ：GraphQL 以類似於 SOAP 的方式提供所發生錯誤的詳細資訊。它的錯誤訊息包括所有解析器，並指向確切的發生故障時的查詢部份。

靈活的許可權 ：GraphQL 允許選擇性地公開某些功能，同時保留私人資訊。而相對應的是，REST 體系架構不能僅顯示部份數據，要麽是全部數據，要麽是沒有數據。

GraphQL 的不足

效能問題 。GraphQL 權衡了復雜性，來實作其強大功能。一個請求中的巢狀欄位太多會導致系統過載。因此，對於復雜的查詢，REST 仍然是更好的選擇。

緩存復雜度 。由於 GraphQL 不再使用 HTTP 緩存語意，因此使用者需要額外自訂緩存。

大量的預開發教育 。由於沒有足夠的時間來了解 GraphQL 的某個操作和 SDL，因此許多計畫決定采用眾所周知的 REST 方法。

GraphQL 的用例

移動 API 。在這種情況下，網路效能和單個訊息有效負載最佳化很重要。因此，GraphQL 為行動裝置提供了更有效的數據載入方式。

復雜的系統和微服務 。GraphQL 能夠隱藏其 API 背後的多個系統整合的復雜性。GraphQL 從多個地方聚合數據，並將它們合並為一個全域的模式。對於隨時間推移而逐漸擴充套件的遺留基礎架構或第三方 API 來說，這尤其重要。

哪種 API 模式最適用你的用例？

每個 API 計畫都有不同的限制和需求。通常，API 架構的選擇取決於：

在了解了每種設計風格的利與弊之後，API 設計人員可以選擇最適合計畫的那一種。

具有強耦合性的 RPC 很適用於內部微服務，但它對外部 API 或者 API 服務而言不是一個好的選擇。

SOAP 的使用有些麻煩，但它強大的安全拓展使它在計費操作、預訂系統和支付方面是無可替代的。

REST 是針對 API 的最高級別的抽象和最佳模型。但它往往會有些「啰嗦」而增加系統的負擔 —— 如果你使用的是行動裝置，這是個問題。

GraphQL 在數據獲取方面向前邁出了一大步，但並不是每個人都有足夠的時間後精力來掌握它。

歸根結底，去針對一些小型的用例來嘗試某種特定 API 架構，並去了解它是否適合你的用例以及是否解決了你的問題，這樣做是比較合適的。如果它適用於你的用例，就可以嘗試擴充套件並檢視它是否適用於更多的用例。

你還有什麽想要補充的嗎？

GPT-4o深夜炸場！AI即時視訊通話絲滑如人類！重磅來襲！我們系統已全部灰度到GPT-4o ！！！

最後給大家推薦一個ChatGPT 4.0國內網站，是我們團隊一直在使用的，我們對接是OpenAI官網的帳號，給大家打造了一個一模一樣ChatGPT，很多粉絲朋友現在也都透過我拿這種號，價格不貴，關鍵還有售後。

一句話說明：用官方一半價格的錢，一句話說明:用跟官方 ChatGPT4.0 一模一樣功能，無需魔法，無視封號，不必擔心次數不夠。

最大優勢：可實作會話隔離！突破限制：官方限制每個帳號三小時可使用40次4.0本網站可實作次數上限之後，手動切換下一個未使用的帳號【相當於一個4.0帳號，同享受一百個帳號輪換使用許可權】

最後，再次推薦下我們的AI星 球 ：

為了跟上AI時代我幹了一件事兒，我建立了一個知識星球社群：ChartGPT與副業。想帶著大家一起探索 ChatGPT和新的AI時代 。

有很多小夥伴搞不定ChatGPT帳號，於是我們決定，凡是這三天之內加入ChatPGT的小夥伴，我們直接送一個正常可用的永久ChatGPT獨立帳戶。

不光是增長速度最快，我們的星球品質也絕對經得起考驗，短短一個月時間，我們的課程團隊釋出了 8個專欄、18個副業計畫 ：

簡單說下這個星球能給大家提供什麽：

1、不斷分享如何使用ChatGPT來完成各種任務，讓你更高效地使用ChatGPT，以及副業思考、變現思路、創業案例、落地案例分享。

2、分享ChatGPT的使用方法、最新資訊、商業價值。

3、探討未來關於ChatGPT的機遇，共同成長。

4、幫助大家解決ChatGPT遇到的問題。

5、 提供一整年的售後服務，一起搞副業

星球福利：

1、加入星球4天後，就送ChatGPT獨立帳號。

2、邀請你加入ChatGPT會員交流群。

3、贈送一份完整的ChatGPT手冊和66個ChatGPT副業賺錢手冊。

其它福利還在籌劃中... 不過，我給你大家保證，加入星球後，收獲的價值會遠遠大於今天加入的門票費用 ！

本星球第一期原價 399 ，目前屬於試營運，早鳥價 149 ，每超過50人漲價10元，星球馬上要來一波大的漲價，如果你還在猶豫，可能最後就要以 更高價格加入了 。。

早就是優勢。 建議大家盡早以便宜的價格加入！

歡迎有需要的同學試試，如果本文對您有幫助，也請幫忙點個 贊 + 在看 啦！❤️

在 還有更多優質計畫系統學習資源，歡迎分享給其他同學吧！

PS：如果覺得我的分享不錯，歡迎大家隨手點贊、轉發、在看。

最後給讀者整理了一份BAT大廠面試真題，需要的可掃碼加微信備註：「面試」獲取。

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝!

END

最近面試BAT，整理一份面試資料【Java面試BAT通關手冊】，覆蓋了Java核心技術、JVM、Java並行、SSM、微服務、資料庫、數據結構等等。在這裏，我為大家準備了一份2021年最新最全BAT等大廠Java面試經驗總結。

別找了，想獲取史上最全的Java大廠面試題學習資料

掃下方二維碼回復「面試」就好了

歷史好文：

掃碼關註「後端架構師」，選擇「星標」公眾號

重磅幹貨，第一時間送達