我們知道，兩個單獨的應用程式需要中介程式才能相互通訊。因此，開發人員通常會搭建橋樑（應用程式程式設計介面），以允許一個系統訪問另一個系統的資訊或功能。

為了快速、大規模地整合應用程式，API是使用協議或規範實現的，這些協議或規範定義了透過網路傳遞的訊息的語義和語法。這些規範組成了API體系結構。

隨著時間的推移，不同的API架構風格已經發布。 每一種都有自己的標準化資料交換模式，選擇的豐富引發了關於哪種架構風格是最好的無休止的爭論。

API styles over time, Source: Rob Crowley

今天，許多API消費者稱REST為“安息”，併為GraphQL歡呼，而十年前則相反，REST是取代SOAP的贏家。這些觀點的問題在於，他們是片面地選擇一種技術本身，而不是考慮它的實際屬性和特性如何與當前的情況相匹配。

Four major API styles compared

遠端過程呼叫（RPC）：在另一個系統上呼叫功能

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

最初的XML-RPC存在問題，因為確保XML有效載荷的資料型別非常困難。所以，後來一個RPC API開始使用更具體的JSON-RPC規範，它被認為是比SOAP更簡單的替代品。 gRPC是Google在2015年開發的最新RPC版本，gRPC對負載均衡、跟蹤、健康檢查和認證的支援可插拔，非常適合連線微服務。

/ RPC如何工作 /

客戶端呼叫一個遠端過程，將引數和附加資訊序列化為訊息，並將訊息傳送到伺服器。伺服器在收到訊息後，對其內容進行反序列化，執行請求的操作，並將結果發回給客戶端。伺服器存根和客戶端存根負責引數的序列化和反序列化。

Remote Procedure Calling Mechanism, Source: Guru99

/ RPC優點 /

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

易於新增的功能。 如果我們對API有了新的需求，我們可以很容易地新增另一個端點來執行這個需求：

編寫一個新函式並將其放到一個端點後，現在客戶端可以打這個端點，並獲得滿足設定需求的資訊。

高效能。 在提供高效能的網路上，輕量級有效載荷很容易實現，這對於共享伺服器和在工作站網路上執行的平行計算非常重要。RPC能夠最佳化網路層，每天在不同服務之間傳送大量的訊息，效率非常高。

/ RPC缺點 /

與底層系統緊密耦合。一個API的抽象層次有助於其可重用性。它與底層系統的關係越緊密，對其他系統的可重用性就越低。 RPC與底層系統的緊密耦合，不允許在系統中的函式和外部API之間建立抽象層，這就引發了安全問題，因為很容易將底層系統的實現細節洩露到API中。RPC的緊密耦合使得可擴充套件性要求和鬆散耦合的團隊很難實現，因此，客戶端要麼擔心呼叫特定端點的任何可能的副作用，要麼試圖弄清楚呼叫哪個端點，因為它不理解伺服器是如何命名其函式的。

發現性低。在RPC中，無法內省API或傳送請求，也無法根據請求理解呼叫什麼函式。

函式爆炸。建立新函式很容易。因此，我們不是編輯現有的函式，而是建立新的函式，並以一大堆難以理解的重疊函式結束。

/ RPC用例 /

RPC模式大約在80年代開始使用，但這並不會自動使其過時。像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格式的、高度標準化的網路通訊協議。 SOAP在Microsoft於XML-RPC發行一年後釋出，從中繼承了很多東西。 當REST緊隨其後時，它們首次並行使用，但很快REST贏得了流行度競賽。

/ SOAP如何工作 /

XML資料格式背後拖著很多形式化的東西，配合龐大的訊息結構，使得SOAP成為最囉嗦的API風格。

SOAP訊息包括：

包含請求或響應的正文標頭（如果訊息必須確定任何具體要求或額外要求），以及故障通知在整個請求處理過程中可能發生的任何錯誤。

An example of the SOAP message. Source: IBM

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

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

/ SOAP優點 /

與語言和平臺無關。建立基於Web的服務的內建功能允許SOAP處理通訊並做出與語言和平臺無關的響應。

繫結到各種傳輸協議。SOAP在傳輸協議方面很靈活，可以適應多種情況。

內建錯誤處理。SOAP API規範允許返回帶有錯誤程式碼和解釋的重試XML訊息。

許多安全擴充套件。與WS-Security協議整合後，SOAP可以滿足企業級的事務質量。它提供了交易內部的隱私和完整性，同時允許在訊息層面進行加密。

SOAP訊息級別的安全性：頭元素中的認證資料和加密的主體

/ SOAP缺點 /

如今，由於多種原因，許多開發人員對必須整合SOAP API的想法感到不安。

僅XML。 SOAP訊息包含大量元資料，並且僅支援請求和響應的詳細XML結構。

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

狹義的專業知識。構建SOAP API伺服器需要深入瞭解所涉及的所有協議及其高度限制的規則。

/ SOAP用例 /

目前，SOAP架構最常見的是用於企業內部或與其信任的合作伙伴的整合。

高度安全的資料傳輸。SOAP嚴格的結構、安全和授權能力使它成為在API和客戶端之間執行正式軟體契約的最合適的選擇，同時遵守API提供者和API消費者之間的合法契約。這就是為什麼金融組織和其他企業使用者選擇SOAP的原因。

REST：使資料可用作資源

REST是一種由一組架構約束定義的自解釋API架構風格，旨在為許多API消費者廣泛採用。

今天最常見的API風格最初是由Roy Fielding在2000年的博士論文中描述的。REST使伺服器端資料可用簡單的格式表示，通常是JSON和XML。

/ REST如何工作 /

REST並不像SOAP那樣嚴格定義，RESTful架構應該遵守六個架構約束。

統一介面：允許以統一的方式與給定的伺服器進行互動，而不考慮裝置或應用型別。無狀態：處理請求的必要狀態，就像請求本身所包含的那樣，伺服器不需要儲存任何與會話有關的內容。快取客戶端-伺服器架構：允許任何一方獨立進化應用程式的分層系統伺服器向客戶機提供可執行程式碼的能力

事實上，有些服務只是在一定程度上是RESTful的。它們以RPC風格為核心，將較大的服務分解為資源，並有效地使用HTTP基礎設施。但關鍵部分是使用超媒體又名HATEOAS，即Hypertext As The Engine of Application State的縮寫。基本上，這意味著每一個響應，REST API都會提供元資料，連結到所有關於如何使用API的相關資訊。這就是實現客戶端和伺服器解耦的原因。因此，API提供者和API消費者都可以獨立發展而不妨礙他們的交流。

Richardson成熟度模型是實現真正完整和有用的API的一個目標標杆

“HATEOAS是REST的一個關鍵特性。它是真正的REST REST的原因。因為大多數人沒有使用HATEOAS，他們實際上是在使用HTTP RPC。”這是Reddit上表達的一些激進意見。事實上，HATEOAS是REST最成熟的版本。然而，要實現這一目標，需要比目前通常使用和構建的API客戶端先進得多的智慧API是很困難的。所以，如今即使是非常好的REST API也不一定能做到。這也是為什麼HATEOAS主要作為RESTful API設計的長期發展願景。

當一個服務實現了REST的一些功能和RPC的一些功能時，REST和RPC之間確實可能存在一個灰色地帶。REST是基於資源或名詞，而不是基於動作或動詞。

以動詞為中心的RPC與以名詞為中心的REST中的操作相反

在REST中，使用HTTP方法，如GET、POST、PUT、DELETE、OPTIONS，以及希望的PATCH，來完成事情。

/ REST優點 /

解耦客戶端和伺服器。儘可能地將客戶端和伺服器解耦，REST可以實現比RPC更好的抽象。一個具有抽象層次的系統，能夠對其細節進行封裝，以更好地識別和維持其屬性。這使得REST API具有足夠的靈活性，可以隨著時間的推移而發展，同時保持一個穩定的系統。

可發現性。客戶端和伺服器之間的通訊描述了一切，因此不需要外部文件就能理解如何與REST API互動。

快取友好。重用了很多HTTP工具，REST是唯一允許在HTTP層面上快取資料的風格。相比之下，在任何其他API上實現快取都需要配置一個額外的快取模組。

支援多種格式。支援多種格式儲存和交換資料的能力是目前REST成為構建公共API的主流選擇的原因之一。

/ REST的缺點 /

沒有單獨的REST結構。構建REST API沒有確切的正確方法。如何對資源進行建模，對哪些資源進行建模，將取決於每個場景。這使得REST在理論上很簡單，但在實踐中卻很難。

大載荷。REST會返回很多豐富的元資料，這樣客戶端就可以僅僅從它的響應中瞭解應用狀態的一切必要資訊。對於一個擁有大量頻寬容量的大型網路管道來說，這種豐富的元資料並不是什麼大問題。但情況並不總是這樣，這是Facebook在2012年推出GraphQL風格描述的關鍵驅動因素。

過度獲取和獲取不足問題。REST響應包含的資料要麼太多，要麼不夠，經常會產生對另一個請求的需求。

/ REST用例 /

管理API。最常見的API型別是專注於管理系統中的物件並面向許多使用者的API。REST使此類API具有強大的可發現性和良好的文件，並且非常適合這種物件模型。

簡單的資源驅動型應用程式。REST是連線不需要靈活查詢的資源驅動型應用的寶貴方法。

GraphQL：僅查詢所需的資料

要呼叫REST API多次才能返回所需資訊，所以GraphQL的發明是為了改變遊戲規則。

GraphQL是一種描述如何進行精確資料請求的語法。對於具有大量相互引用的複雜實體的應用程式資料模型來說，實現GraphQL是值得的。

如何從GraphQL端點只檢索需要的資料

如今，GraphQL的生態系統正在透過Apollo、GraphiQL和GraphQL Explorer等庫和強大的工具進行擴充套件。

/ GraphQL如何工作 /

GraphQL從構建一個模式開始，它是對你在GraphQL API中可能進行的所有查詢以及它們返回的所有型別的描述。構建模式很困難，因為它需要在模式定義語言(SDL)中使用強型別。

在查詢之前有了模式，客戶可以根據模式來驗證他們的查詢，以確保伺服器能夠響應它。在到達後端應用時，GraphQL操作會針對整個模式進行解釋，並與前端應用的資料進行解析。API向伺服器傳送一個大型查詢，返回一個JSON響應，其中包含我們請求的資料的確切形狀。

在GraphQL中執行查詢

除了RESTful CRUD操作外，GraphQL還有訂閱功能，可以從伺服器上獲得實時通知。

/ GraphQL的優點 /

型別化的模式。GraphQL提前公佈了它能做的事情，這提高了它的可發現性，透過將客戶端指向GraphQL API，我們可以發現有哪些查詢。

能很好地適應圖形類資料。資料關係很深，但不適合平面資料。

沒有版本控制。版本化的最佳實踐是完全不對API進行版本化。

雖然REST提供了多個API版本，但GraphQL使用的是一個單一的、不斷髮展的版本，可以持續地訪問新的功能，並有助於更乾淨、更可維護的伺服器程式碼。

詳細的錯誤訊息。與SOAP類似，GraphQL提供了發生錯誤的細節。它的錯誤資訊包括了所有的解析器，並提到了出錯的具體查詢部分。

靈活的許可權。GraphQL允許有選擇地暴露某些功能，同時保留私人資訊。同時，REST架構並不顯示資料的部分。要麼全有，要麼全無。

/ GraphQL的缺點 /

效能問題。GraphQL以複雜度換取其強大的功能。在一個請求中擁有過多的巢狀欄位會導致系統過載。所以，對於複雜的查詢，REST仍然是一個更好的選擇。

快取複雜。由於GraphQL並沒有重用HTTP快取語義，所以需要進行自定義快取工作。

大量的開發前教育。由於沒有足夠的時間來了解GraphQL的小眾操作和SDL，許多專案決定採用眾所周知的REST方法。

/ GraphQL用例 /

移動裝置API。在這種情況下，網路效能和單條訊息的有效載荷最佳化是很重要的。所以，GraphQL為移動裝置提供了更高效的資料載入。

複雜的系統和微服務。GraphQL能夠將多個系統整合的複雜性隱藏在其API背後。它從多個地方聚合資料，然後將它們合併到一個全域性模式中。這對於傳統的基礎設施或隨著時間的推移而擴充套件的第三方API來說，尤其重要。

哪種API模式最適合您的用例？

每個API專案都有不同的要求和需求。通常情況下，架構的選擇取決於：

使用的程式語言您正在開發的環境，以及你所擁有的資源，包括人力和財力。

瞭解每一種設計風格的所有權衡，API設計師就可以選擇最適合專案的那一種。

憑藉其緊密的耦合性，RPC適用於內部微服務，但對於強大的外部API或API服務來說，它不是一個好選擇。

SOAP雖然麻煩，但其豐富的安全功能對於計費業務、預訂系統和支付來說，仍然是不可替代的。

REST具有API的最高抽象和最佳建模。但這往往會增加線上和聊天的負擔——如果您使用的是移動裝置，這是不利的一面。

GraphQL是資料獲取方面的一大進步，但並不是每個人都有足夠的時間和精力去掌握它。

在一天結束的時候，用一個特定的風格嘗試幾個小的用例是有意義的，看看它是否適合你的用例並解決你的問題。如果確實如此，就嘗試擴充套件，看看它是否適合更多的用例。

最近整理了一份優質影片教程資源，想要的可以關注我然後私信“666”即可免費領取哦！如果文章對你有所啟發和幫助，可以點個關注、收藏、轉發，也可以留言討論，這是對作者的最大鼓勵。