4 種主流的 API 架構風格對比

不同時間的 API 架構風格，圖源：Rob Crowley

四種 API 架構風格

1. 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 就能做到。

2. SOAP：使數據作爲服務可用

SOAP 的工作機制

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

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

一個信封標籤：用於開始和結束每條消息
包含請求或響應的正文
一個標頭：用於表示消息是否由某些規範或額外要求的來確認
故障通知：包含了可能在請求處理過程只能夠發生的任何錯誤

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

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

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

SOAP 的優勢

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

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

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

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

SOAP 消息級別的安全性：在標頭元素的認證數據以及加密的正文

SOAP 的不足

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

僅使用 XML 。SOAP 消息包含大量的元數據，並且在請求和響應時僅支持繁冗的 XML 格式。

重量級 。由於 XML 文件的大小，SOAP 服務需要很大的帶寬。

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

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

SOAP 的用例

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

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

3. REST：使數據作爲資源可用

REST 的工作機制

統一接口：無論設備或應用程序類型如何，都可以採用統一的方式與給定的服務端進行交互。
無狀態：請求本身包含處理該請求所需要的狀態，並且服務端不存儲與會話相關的任何內容。
緩存
客戶端 - 服務器體系結構：允許雙方獨立發展
應用程序的層級系統
服務端向客戶端提供可執行代碼的能力

理查森成熟度模型作爲實現真正完整且有用的 API 架構的目標。圖源：Kristopher Sandoval

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

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

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

圖源：Thomas David

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 是一種非常有效的方法。

4. GraphQL：僅請求所需要的數據

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

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

圖片

如何從 GraphQL 端點僅獲取所需要的數據，圖源：Mohit Tikoo

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

GraphQL 的工作機制

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

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

圖片

GraphQL 的查詢語句執行，圖源：Jonas Helfer

除了包含 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 來說，這尤其重要。

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

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

所使用的編程語言，
你的開發環境，以及
你的資源預算，包括人力資源和財務資源。

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

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

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

REST 是針對 API 的最高級別的抽象和最佳模型。但它往往會有些 “囉嗦” 而增加系統的負擔 —— 如果你使用的是移動設備，這是個問題。

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

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

原文鏈接：

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/A2rwGMuMRCWokvT2YAnKyw