Categories
程式開發

API已死,APIs萬歲


在本文中,作者將重點介紹 REST API 的統治地位是如何衰退的,以及生態系統是如何走向民主的。 API Is Dead – Long Live the APIs!

歷史背景

正如我之前在博客中所描述的那樣,在一個企業內部,隨著時間的推移,技術會分層部署。許多較老的技術仍然能帶來價值,使其遠未過時。考慮到儘管許多企業正在經歷數字化轉型,但它們的舊層和深層中所包含的技術和相關數據仍然具有價值。不能簡單地將它們移除,因為畢竟是在下面的層才能為放置新柱子奠定基礎。這些層中的許多通常都具有遺留接口,如 CORBA、RMI、SOAP 等。

那麼,為什麼我們要在層上繼續添加層呢?如果以古生物學家的身份來探討這個問題,我們會採集一個核心樣本,分析每一層;針對技術也可以來嘗試這個方法,並深入到各個層次。每一層都代表一個歷史視圖,在最頂層 / 最外層,我們可以找到 REST,它是當今最普及的技術。就在 REST 之下,我們會遇到面向服務架構(Service Oriented Architecture,SOA)層。停下來思考下,為什麼 REST 取代了 SOA ?雖然原因有很多,但可以說最主要的原因是 REST 極大地簡化了客戶端可訪問性的問題,使用 REST,可以交換的是 JSON 而不是 XML,從而簡化了在瀏覽器中的使用。

此外,REST 還有一個簡化的方法,其動詞 GET、PUT、POST 等允許使用簡單的通用工具,比如 cURL 和 Postman。幾乎用任何語言創建自己的客戶端都非常簡單。

另一方面

雖然該協議與平台無關,但是 SOAP 使用 XML,這使得在瀏覽器中使用它變得冗長而痛苦。此外,由 WS-* 標準增加的複雜性層意味著編寫服務器端很容易,但編寫客戶端卻很痛苦。客戶端實現需要使用第三方工具以我們所選擇的語言來生成客戶端代碼,這會產生繁重的依賴關係。

當我們深入研究技術層時,我們會發現類似的情況。 SOAP 曾經也是王者,它取代了 CORBA 和 RPC 等技術。 REST 從 SOAP 那里奪走了王位,而今天,REST 的王位正受到來自民主呼聲的挑戰。

誰是能從 REST 手中奪取王位的挑戰者呢?有幾個有追求的人在覬覦 REST 的王位。這些人可以分為三類:“服務器到客戶端”、“基於事件”或“數據訪問”家族。就像在《權力的遊戲》中一樣,挑戰者可以按照他們的家族血統來劃分(House Targaryen、House Lannister、House Stark 等)

“反向 API”家族:The House of “Reverse API”

這個家族的標誌是電話,既是服務器調用客戶端,而不能反過來調用。

Webhooks:Webhooks 有時被稱為“反向 API”,因為調用的發起方是服務器而不是客戶端;服務器將狀態變更通知客戶端。客戶端應用程序註冊一個回調 URL,當服務器上的資源發生狀態變更時,就可以訪問該 URL。客戶端應用程序將收到狀態變更的 HTTP 負載通知。 Webhooks 是一種流行的基於事件的機制,該機制可以在網上找到(GitHub、Stripe、Twilio)。它們不是銀彈,因為它們不提供有保證的交付,很少重試,可能會不同步,並且在事件量很大時(可能需要反壓機制) 會給客戶端帶來很大的壓力。

WebSocket:WebSocket 是一種傳輸協議,它通過一個 TCP 套接字連接在服務器和客戶端之間建立一個持久的雙向通信通道。當服務器到客戶端或客戶端到服務器需要近實時交換時,WebSocket 是一個不錯的選擇。這克服了 HTTP 請求 / 響應機制的限制(例如客戶端輪詢及相關的開銷)。 WebSocket 適用於需要實時更新的應用程序,因為服務器可以在連接上隨時推送數據。所有現代瀏覽器都支持 WebSocket。

SSE: 服務器發送事件(Server-Sent Events,SSE)是一種服務器推送技術,它允許客戶端通過帶有內置自動重連機制的 HTTP 連接接收來自服務器的自動更新。服務器發送事件 EventSource API 作為 HTML5 的一部分被進行了標準化。 SSE 是通過傳統 HTTP 發送的,這意味著它不需要特殊的協議或服務器實現即可正常工作。另一方面,WebSockets 需要全雙工連接和新的 Web Socket 服務來處理協議。 SSE 適用於不需要從客戶端發送數據,但需要通過某些服務器操作進行更新(例如股票行情、共享設施更新、好友狀態更新等)的場景。

“事件驅動”家族:The House of “Event-Driven”

這個家族的標誌是 Kafka 圖標,因為它是“事件驅動”的主導者。

這個家主要由三個字符組成,即兩個基於提交日誌 Apache Kafka 和 NATS 的消息傳遞系統,以及 RabbitMQ 的消息隊列。這些技術已經成為基於異步事件的微服務架構的實際支柱。基於事件消息傳遞的架構會導致服務之間的極度鬆散耦合,這對於事件驅動系統非常有用。在這些架構中,諸如 CQRS(命令查詢職責分離)和事件源等不同的設計模式非常流行。因為 JSON 太冗長,發送到隊列的消息使用 Proto Buf、Avro 或 Thrift 定義,事件將被內部微服務消費。

由於基於事件的系統是異步的,因此系統本身將具有最終一致性。這導致開發人員不得不處理服務之間的不一致數據。根據所使用的消息傳遞主幹,可能必須考慮接收重複事件、無序事件或丟失事件(保證交付)的處理。與傳統的 REST API 相比,可用於基於事件的開發(設計、調試、測試、監控)工具更加不成熟。

有兩個新興項目值得跟踪和投入:

  • 由雲原生基金會(Cloud Native Foundation,CNCF)孵化的 CloudEvents 項目正在嘗試定義與供應商無關的事件格式,以便在不同的雲系統之間進行轉換。

  • AsyncAPI 的目標是使事件驅動的架構更簡單,並且像 REST API 一樣為開發人員所熟悉,它將包括文檔、代碼生成、發現和事件管理。

gRPC 家族:The House of gRPC

gRPC 的名稱中包含了一些線索;“g” 來自 Google 和 RPC,因為它是為遠程過程調用(RPC)而設計的。這是 CNCF 的一個頂級項目。 gRPC 通常在組織內部使用(即在微服務架構中),這樣我們可以控制消費者和提供者。因為它使用了 HTTP 2.0,gRPC 相較於傳統的 HTTP 1.1 REST 調用有較高的性能。服務定義是使用了 Proto Buf ,由此,可以用多種語言生成客戶端和服務端存根。 gRPC 支持雙向流和可插拔的身份驗證機制。

“GraphQL”家族:The House of “GraphQL”

GraphQL:GraphQL API 適用於移動應用程序,並且有助於避免使用 REST API 時出現的閒聊問題。借助 GraphQL,客戶端可以確定它們所需的數據、所需怎樣的數據以及所需的數據格式,而無需遍歷多個 REST 請求 / 響應來查找應用程序所需的資源。這將減少調用客戶端所需建立的網絡連接次數,並確保它們只檢索所需的數據。如果客戶端是移動應用程序或單頁應用程序(single-page application,SPA),則可以提供更好的用戶體驗。 2015 年,Facebook 公開發布了 GraphQL 規範和參考實現。但今天,GraphQL 的管理工作由 GraphQL 基金會負責。

為什麼說GraphQL是API的未來?

“OData”家族:The house of “OData”

OData:OData(開放數據協議)是一個 OASIS 標準,它定義了構建和使用 RESTful API 的最佳實踐。它最初是由微軟在 2007 年開發的。 OData 是 HTTP、REST 和 JSON 之上的一組通用約定。如果採用這些約定,則意味著 API 提供者最終將以一種標準且一致的方式來處理諸如查詢、分頁、排序​​和過濾 API 之類的問題。正是由於這些約定,如果我們看到了一個 OData 服務,那麼我們也就看到了所有服務,並且實現消費應用程序變得更加容易。 OData API 經常出現在運行 Microsoft 和 SAP 服務的生態系統中。

“IoT”家族:The House of “IoT”

鑑於物聯網設備的爆炸性增長,這個家族牢牢地坐落在億萬富翁俱樂部裡。

MQTT(消息隊列遙測傳輸): 是一種基於發布 – 訂閱的 ISO 標準消息傳遞協議。它在 TCP/IP 協議之上工作。設計它是用於與需要“小代碼佔用”的遠程位置的連接或我們需要限製網絡帶寬的情況。因此,對於帶寬昂貴且所需開銷最小的嵌入式系統等客戶端來說,它是一種完美的協議。

AMQP(高級消息隊列協議) 是異步通信中最流行的協議之一。 RabbitMQ 和 ActiveMQ 是一些流行實現,或者有像 AWS MQ 這樣的託管解決方案。 AMQP 是面向消息中間件的開放標準應用層協議。 AMQP 的主要特點是消息定向、排隊、路由、可靠性和安全性。與 MQTT 相比,AMQP 具有更多特性,因此,它更適合在需要更高處理和內存要求的客戶端系統上運行。因此,它被視為一個相當繁重的協議,在物聯網的傳感器 / 嵌入式世界中不能很好地發揮作用。

結論

正如本文所示,REST API /Services 的君主統治已經過去了。所需的 API 技術生態系統將專用於消費客戶端應用程序的需求。生態系統中不會只有一個贏家,而是有許多贏家,這取決於客戶所需的經驗。沒有一項技術會永遠坐上王位上,這是一種民主,客戶決定將由誰來代表他們!

API 已死了——API 萬歲!

API is dead,long live the APIs