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