架構師該如何為應用選擇合適的API
前言：
架構師的主要活動是做出正確的技術決策。選擇合適的API是一項重要的技術決策。那么今天就看看API的選擇問題。
應用程序編程接口(API)是一種計算接口，它定義了多個軟件中介之間的交互。它定義了可以進行的調(diào)用或請求的類型，如何進行調(diào)用，應使用的數(shù)據(jù)格式，遵循的約定等。它還可以提供擴展機制，以便用戶可以以各種方式擴展現(xiàn)有功能。在不同程度上。API可以是完全定制的，特定于組件，也可以基于行業(yè)標準進行設計以確?；ゲ僮餍?。有些API必須記錄在案，而其它API則經(jīng)過設計，以便可以“查詢”它們以確定支持的功能。由于其他組件/系統(tǒng)僅依賴于API，因此提供API的系統(tǒng)可以(理想地)在API的“后面”更改其內(nèi)部詳細信息，而不會影響其用戶。
正如上述的定義所述，API提供了多個軟件之間的交互。所以我們這里強調(diào)的是交互性。我們在使用任何的語言開發(fā)一個應用的時候，都會提供內(nèi)部的基于該語言的API，這種內(nèi)部的API不是我們今天要討論的內(nèi)容，因為這種內(nèi)部的交互不涉及到軟件之間。我們今天要討論的API主要要涉及到系統(tǒng)之間的交互。對于具體應用而言，更多是進程之間(本機)，主機之間(本網(wǎng)絡)，服務之間(可能跨域廣域網(wǎng))的交互。
目錄：
1、CORBA
2、XML-RPC / SOAP
3、REST
4、GraphQL
5、gRPC
最早在Unix/Linux的編程領域，提供了進程間通信的手段，例如：管道，信號量，消息隊列，套接字(Socket)等。如果你的應用是由不同語言編寫的，那么這里只能選擇Socket通信作為應用之間的API手段。但是Socket通信是一種非常低Level的通信手段，它以底層的數(shù)據(jù)包作為抽象和通信內(nèi)容，很難維護和使用。當然還有一些其它的系統(tǒng)間通信的手段例如通過共享文件或者FTP的方式，同樣面臨著各種不便。我們希望提供一種更高級的交互手段，直接和我的應用的抽象交互，這些抽象可能是方法，函數(shù)和對象。于是就有了各種支撐這些需求的API技術。
早期的進程間通信技術包括：
- DCOM ( Distributed Component Object Model )分布式組件對象模型，這個是微軟的技術，只能用于Windows平臺， 通過網(wǎng)絡實現(xiàn)遠程對象間的通信
- RMI ( Remote Method Call) Java的遠程方法調(diào)用，這個是Java自己的RPC，只能用于Java應用之間的遠程調(diào)用。
- JNI Java的本地接口， 支持Java應用調(diào)用本地方法，這個是跨越語言障礙的，但是僅僅局限于Java應用調(diào)用其它的本地應用，不具備互操作性，是個單向通道。
1.CORBA
在1991年一種名叫CORBA ( Common Object Request Broker Architecture ) 的技術出現(xiàn)了，我記得我的第一份工作是一個電信網(wǎng)管系統(tǒng)的開發(fā)，我們就是利用CORBA來實現(xiàn)不同的系統(tǒng)之間的通信。主要涉及C++和Java。
CORBA和之前提到的DCOM和RMI類似，都提供了遠程的對象/方法調(diào)用，但是CORBA是一種與語言和實現(xiàn)無關的技術，我記得我們當時的測試腳本使用了TCL，也有CORBA的實現(xiàn)，也就是說CORBA定了與語言解耦的系統(tǒng)間通信的標準。這個是它的最大的優(yōu)勢。那個年代的應用，采用CORBA作為系統(tǒng)間的通信手段非常普遍。
開發(fā)CORAB的過程從IDL的定義開始，用戶通過IDL定義了對象，然后在Server端實現(xiàn)該對象的應用邏輯，在Client端調(diào)用該對象。
但是CORBA并非沒有缺點，否則我們也不會很少再看見今天的應用用CORAB作為API的了。他的主要問題是：
- 對象的生命周期管理比較復雜。遠程對象的發(fā)現(xiàn)，創(chuàng)建和銷毀都會帶來問題
- 整個CORAB的架構比較復雜，看看它的架構圖就知道了
總之，今天你要開發(fā)一個引用，除非要個已有系統(tǒng)交互，你應該不會選擇CORBA。
2.XML-RPC / SOAP
XML-RPC發(fā)表于1998年，由UserLand Software(UserLand Software)的Dave Winer及Microsoft共同發(fā)表。后來在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協(xié)議
下面是一個 XML-RPC的請求/響應的例子：
- <?xml version="1.0"?>
- <methodCall>
- <methodName>examples.getStateName</methodName>
- <params>
- <param>
- <value><i4>40</i4></value>
- </param>
- </params>
- </methodCall>
- <?xml version="1.0"?>
- <methodResponse>
- <params>
- <param>
- <value><string>South Dakota</string></value>
- </param>
- </params>
- </methodResponse>
SOAP是 Simple Object Access Protocol 的縮寫。SOAP為Web服務提供了Web服務協(xié)議棧的Messaging Protocol層。它是一個基于XML的協(xié)議，由三部分組成：
- 一個信封，它定義了消息結構以及如何處理它
- 一組用于表達應用程序定義的數(shù)據(jù)類型實例的編碼規(guī)則
- 表示過程調(diào)用和響應的約定
SOAP具有三個主要特征：
- 可擴展性(安全性和WS-Addressing在開發(fā)中)
- 中立性(SOAP可以通過HTTP，SMTP，TCP，UDP等任何協(xié)議進行操作)
- 獨立性(SOAP允許任何編程語言)
作為SOAP過程可以執(zhí)行的操作的示例，應用程序可以將SOAP請求發(fā)送到啟用了帶有搜索參數(shù)的Web服務的服務器(例如，房地產(chǎn)價格數(shù)據(jù)庫)。然后，服務器返回SOAP響應(包含結果數(shù)據(jù)的XML格式的文檔)，例如價格，位置，功能。由于生成的數(shù)據(jù)采用標準化的機器可解析格式，因此發(fā)出請求的應用程序可以直接將其集成。
SOAP體系結構由以下幾層規(guī)范組成：
- 訊息格式
- 郵件交換模式(MEP)
- 底層傳輸協(xié)議綁定
- 消息處理模型
- 協(xié)議可擴展性
這里是一個SOAP消息的例子：
- POST /InStock HTTP/1.1
- Host: www.example.org
- Content-Type: application/soap+xml; charset=utf-8
- Content-Length: 299
- SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
- <?xml version="1.0"?>
- <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org">
- <soap:Header>
- </soap:Header>
- <soap:Body>
- <m:GetStockPrice>
- <m:StockName>T</m:StockName>
- </m:GetStockPrice>
- </soap:Body>
- </soap:Envelope>
相比較XML-RPC，它的功能更多，當然消息結構也更復雜。
SOAP是W3C推薦的Webservice標準，一度也是非常的流行，但是我們看到基于XML的消息比較復雜，消息本身因為XML的原因，有相當多的開銷。于是后面又有了基于JSON的RPC格式。但總的來說，SOAP也已經(jīng)是昨日黃花，當今的應用構建，你選它的概率應該也不大了。
3.REST
REST是當今最為流行的API。因為大量的Web應用采用REST作為其API的選擇。REST是 Representational State Transfer 的縮寫。是Roy Thomas Fielding博士于2000年在他的博士論文中提出來的一種萬維網(wǎng)軟件架構風格。
目的是便于不同軟件/程序在網(wǎng)絡(例如互聯(lián)網(wǎng))中互相傳遞信息。表現(xiàn)層狀態(tài)轉換是根基于超文本傳輸協(xié)議(HTTP)之上而確定的一組約束和屬性，是一種設計提供萬維網(wǎng)絡服務的軟件構建風格。符合或兼容于這種架構風格(簡稱為 REST 或 RESTful)的網(wǎng)絡服務，允許客戶端發(fā)出以統(tǒng)一資源標識符訪問和操作網(wǎng)絡資源的請求，而與預先定義好的無狀態(tài)操作集一致化。因此表現(xiàn)層狀態(tài)轉換提供了在互聯(lián)網(wǎng)絡的計算系統(tǒng)之間，彼此資源可交互使用的協(xié)作性質(interoperability)。
相對于其它種類的網(wǎng)絡服務，例如SOAP服務，則是以本身所定義的操作集，來訪問網(wǎng)絡上的資源。目前在三種主流的Web服務實現(xiàn)方案中，因為REST模式與復雜的SOAP和XML-RPC相比更加簡潔，越來越多的Web服務開始采用REST風格設計和實現(xiàn)。所以我們可以看到軟件的發(fā)展，大體是從復雜變得簡單，只有簡單的東西才會變得更有生命力。
為了使任何應用程序真正實現(xiàn)RESTful，必須遵循六個體系結構約束：
- 統(tǒng)一接口：意味著必須向Web應用程序中的API使用者提供API接口。
- 客戶端服務器：客戶端和服務器必須彼此獨立，并且客戶端應僅知道資源的URI。
- 無狀態(tài)：服務器不得存儲與客戶端請求相關的任何內(nèi)容。客戶端負責維護應用程序的狀態(tài)。
- 可緩存的：資源必須可緩存。
- 分層系統(tǒng)：體系結構必須是分層的，這意味著體系結構的組件可以位于多個服務器中。
- 按需代碼：客戶端必須能夠獲取可執(zhí)行代碼作為響應。這是一個可選約束。
基于REST的Web服務被稱為RESTful Web服務。在這些應用程序中，每個組件都是一種資源，可以使用HTTP標準方法通過公共接口訪問這些資源。以下四種HTTP方法通常用于基于REST的體系結構中：
- GET-對資源的只讀訪問。
- POST —創(chuàng)建一個新資源。
- DELETE—刪除資源。
- PUT-更新現(xiàn)有資源/創(chuàng)建新資源。
RESTFul風格API所有的操作都是一個動詞，對應HTTP請求的一種類型。每一個操作都定義了對操作的資源的某種行為。這種抽象，特別適合相當多的Web應用，后臺是一個數(shù)據(jù)庫，每一個REST的端點對應了一張數(shù)據(jù)庫的表，很自然的利用REST操作來實現(xiàn)表的增刪查改。
當然RESTFul的風格也有它的不足：
- 不是所有的應用操作都可以用資源的增刪查改來對應，在實際的開發(fā)中經(jīng)常會需要把一個操作映射為一個資源這種不倫不類的行為。
- REST是同步服務，如果需要可能要引入回調(diào)機制。例如Webhook。
- REST只提供客戶端調(diào)用服務器的選項，不支持服務器端發(fā)起請求。
于是新的API類型會出現(xiàn)來解決這些問題。
4.GraphQL
GraphQL是一個開源的API數(shù)據(jù)查詢和操作語言及實現(xiàn)為了實現(xiàn)上述操作的相應運行環(huán)境。2012年，GraphQL由Facebook內(nèi)部開發(fā)，2015年公開公布。2018年11月7日，F(xiàn)acebook將GraphQL項目轉移到新成立的GraphQL基金會 。
GraphQL規(guī)范概述了5條設計原則，這使其成為現(xiàn)代前端開發(fā)的精心設計的解決方案。讓我們研究一下GraphQL的設計原則。
- 查詢是分層結構的，具有分層和嵌套字段，查詢與響應數(shù)據(jù)一對一匹配。查詢和響應的形狀像樹，可以查詢每個項目的其他嵌套字段。
- 該結構以產(chǎn)品為中心，著重于前端希望如何接收數(shù)據(jù)，并構建交付所需的運行時。這樣一來，就可以向后端請求一個所需的所有數(shù)據(jù)，然后讓服務器根據(jù)GraphQL的規(guī)范從不同的端點獲取數(shù)據(jù)。
- 它使用特定于應用程序的類型系統(tǒng)，使開發(fā)人員能夠確保查詢使用有效類型，并且在執(zhí)行之前在語法上正確。
- GraphQL查詢是在客戶端指定的，因此客戶端確切知道它將以什么格式接收數(shù)據(jù)。
- 帶有GraphQL的服務器結構必須是自包含的，或者可由GraphQL本身查詢。這將啟用功能強大的開發(fā)人員工具，例如GraphiQL或GraphQL Playground，這兩種工具都將使開發(fā)人員能夠準確查看哪些查詢和字段可供他們在服務器中使用。
像RESTful API一樣，GraphQL API旨在處理HTTP請求并提供對這些請求的響應。但是，相似之處到此結束。在REST API建立在請求方法和端點之間的連接上的情況下，GraphQL API設計為僅使用一個始終通過POST請求查詢的端點，通常使用URL yourdomain.com/graphql。
達到GraphQL端點后，客戶端請求的負擔將完全在請求主體內(nèi)處理。該請求主體必須遵守GraphQL規(guī)范，并且API必須具有適當?shù)姆掌鞫诉壿媮硖幚磉@些請求并提供適當?shù)捻憫?。與RESTful API相比，這提供了更流暢的客戶端體驗，后者可能要求客戶端對多個數(shù)據(jù)進行多次請求，并在數(shù)據(jù)返回后進行操作。
如上圖的例子，用戶通過RESTFul的API來請求數(shù)據(jù)，需要兩個GET請求，先獲取Assets，再通過AssetID獲取comments。而通過GraphQL，用戶只需要描述需要請求的數(shù)據(jù)的結構和條件，就可以通過一個請求獲取全部所需要的數(shù)據(jù)，簡化了客戶端與服務器的交互。
GraphQL提供的性能優(yōu)于REST API，可以為前端開發(fā)人員帶來回報。使用GraphQL規(guī)范創(chuàng)建服務器可能需要更多設置和編寫預測性服務器端邏輯來解析和處理請求。盡管GraphQL的安裝成本可能會高于傳統(tǒng)的REST架構，但更具可維護性的代碼，強大的開發(fā)工具以及簡化的客戶端查詢，這些都是不錯的收益。
除了靈活性這個最大的優(yōu)點外，GraphQL還有以下的優(yōu)點：
- 聲明性的數(shù)據(jù)獲取，避免了客戶端和服務器端的額外交互
- 優(yōu)秀的開發(fā)體驗，不需要版本控制，因為引入新的字段不會影響到API查詢。同時客戶端和服務器端的團隊可以并行的獨立工作。
- 強類型的GraphQL模式使得代碼可預測，并及早發(fā)現(xiàn)錯誤。
當然，GraphQL也不是沒有缺點：
- 使用GraphQL，如果您需要查找有關列表或記錄集合的信息，則處理起來會很棘手。例如，如果您想獲取包含其地址的用戶列表的詳細信息，則它將執(zhí)行n + 1個查詢。一個用于用戶列表，然后n查詢每個用戶的地址?，F(xiàn)在它會嚴重影響性能，因此必須非常小心地處理它。
- 很難緩存，緩存API響應的目的主要是為了更快地從將來的請求中獲取響應。與GraphQL不同，RESTful API可以利用HTTP規(guī)范中內(nèi)置的緩存。正如前面提到的，GraphQL查詢可以請求資源的任何字段，因此緩存本質上是困難的。
5.gRPC
gRPC是一個開源的遠程過程調(diào)用框架，用于在服務之間進行高性能的通信。這是將以不同語言編寫的服務與可插拔支持(用于負載平衡，跟蹤，運行狀況檢查和身份驗證)相連接的有效方法。默認情況下，gRPC使用Protobuf(協(xié)議緩沖區(qū))序列化結構化數(shù)據(jù)。通常，對于微服務體系結構，gRPC被認為是REST協(xié)議的更好替代方案。gRPC中的" g"可以歸因于最初開發(fā)該技術的Google。
gRPC是對傳統(tǒng)RPC框架的改編。那么，它與現(xiàn)有的RPC框架有何不同?
最重要的區(qū)別是gRPC使用protobuf 協(xié)議緩沖區(qū)作為接口定義語言進行序列化和通信，而不是JSON / XML。協(xié)議緩沖區(qū)可以描述數(shù)據(jù)的結構，并且可以從該描述中生成代碼，以生成或解析表示結構化數(shù)據(jù)的字節(jié)流。這就是為什么gRPC首選多語言(使用不同技術實現(xiàn))的Web應用程序的原因。二進制數(shù)據(jù)格式使通信更輕松。gRPC也可以與其他數(shù)據(jù)格式一起使用，但是首選的是protobuf。
同樣，gRPC建立在HTTP / 2之上，它支持雙向通信以及傳統(tǒng)的請求/響應。gRPC允許服務器和客戶端之間的松散耦合。在實踐中，客戶端打開與gRPC服務器的長期連接，并且將為每個RPC調(diào)用打開一個新的HTTP / 2流。
如上圖所示，gRPC支持不同模式的客戶端和服務器端的通信方式，極大的方便了不同的互操作能力。
與使用JSON(主要是JSON)的REST不同，gRPC使用Protobuf，這是編碼數(shù)據(jù)的更好方法。由于JSON是基于文本的格式，因此它比protobuf格式的壓縮數(shù)據(jù)要重得多。與REST相比，gRPC的另一個顯著改進是它使用HTTP 2作為其傳輸協(xié)議。REST使用的HTTP 1.1基本上是一個請求-響應模型。gRPC利用HTTP 2的雙向通信功能以及傳統(tǒng)的響應請求結構。在HTTP 1.1中，當多個請求來自多個客戶端時，它們將被一一處理。這會降低系統(tǒng)速度。HTTP 2允許多路復用，因此可以同時處理多個請求和響應。
gRPC的開發(fā)模式和之前提到的CORBA有些類似。Protobuf充當了IDL的角色，然后利用工具生成各種語言的代碼，最后在生成的代碼上實現(xiàn)服務器端和客戶端的邏輯。
gRPC的優(yōu)點是：
- 出色的性能，因為采用protobuf編碼和http/2
- 支持服務器端和客戶端的雙向通信
- 易用，相比REST開發(fā)，需要更少的代碼
缺點：
- 更陡峭的學習曲線
- 支持的語言的種類沒有REST多，當然它還在發(fā)展中
- 因為需要Protobuf的編譯，這帶來了服務器和客戶端一定的耦合，因為接口變動的時候需要重新編譯生成代碼。對于REST，基于不同的工具鏈可能有不同的解決方案
因為其高性能，gRPC更適合被用于系統(tǒng)內(nèi)部組件的通信選擇。在下圖的微服務架構中，對外的服務采用了REST或者GraphQL的API，而內(nèi)部微服務之間使用的是gRPC。
6.總結
好了，看了這么多的API選擇之后，我們做一個小結。
系統(tǒng)間的API選項經(jīng)過多年的發(fā)展，現(xiàn)階段的主流是RESTful API，gRPC 和GraphQL。具體怎么選擇，要結合你的業(yè)務上下文，我的推薦是：
- 對外提供的公開服務，首選RESTFul API，因為它非常成熟穩(wěn)定和流行，語言和工具鏈的支持都很好。
- 如果你希望加速應用的客戶端開發(fā)，GraphQL是個不錯的選擇，提供良好的性能和靈活性
- 如果你的應用特別看重性能，而且主要是內(nèi)部系統(tǒng)之間的交互，建議考慮gRPC
