api發展史特點？

我們想通過查看過去60年api開發（從RPC到現在）的經驗教訓，從而了解各種API類型的優缺點。

為團隊帶來新工具的好處必須與其成本進行權衡，有很多東西需要衡量，有時間學習。由于新技術成本高，所以任何新技術都必須使用得更好，更快或更高效。GraphQL，在我們看來是向前邁出的一大步，并提供了足夠的好處來證明開發成本的合理。

RPC可以說是第一個主要的API模式，它的起源可以追溯到60年代中期的早期計算。當時，計算機仍然如此龐大和昂貴，以至于我們想到的API驅動的應用程序開發的概念大多只是理論上的。帶寬/延遲，計算能力，共享計算時間和物理鄰近等約束迫使工程師考慮分布式系統而不是公開數據的服務。從60年代的ARPANET到90年代中期，使用CORBA和Java的RMI之類的東西，大多數計算機使用遠程過程調用（RPC）相互交互，這是一個客戶端 - 服務器交互模型，客戶端 - 服務器交互模型，客戶端導致過程（或方法）在遠程服務器上執行。

RPC有很多好東西，它的主要原則是允許開發人員將遠程環境中的代碼視為本地代碼，盡管速度慢且不太可靠，從而在其他不同且不同的系統中創建連續性，就像ARPANET出現的很多東西一樣，它已經超前了，因為這種連續性是我們在處理不可靠的異步操作（如數據庫訪問和外部服務調用）時仍然需要努力的。

幾十年來，對于如何允許開發人員將這樣的異步行為嵌入到程序的典型流程中進行了大量研究，如果當時有Promises，Futures和ScheduledTasks這樣的東西，我們的API環境可能會有所不同。

關于RPC的另一個好處是，由于它不受數據結構的限制，因此可以為客戶端編寫高度專業化的方法，這些客戶端可以準確地請求和檢索所需的信息，從而最大限度地減少網絡開銷和較小的有效負載。

但是，有些事情會使RPC變得困難。首先，根據設計，RPC在本地系統和遠程系統之間創建了大量的耦合，即失去了本地和遠程代碼之間的界限。對于某些域，這在客戶端SDK中是可以的，甚至是首選的，但對于客戶端代碼不能很好理解的API，它可能比面向數據的更不靈活。

但更重要的是API方法的擴散潛力，從理論上講，RPC服務公開了一個可以處理任何任務的小巧周到的API。

下一個主要的API類型是SOAP，它誕生于90年代末的Microsoft Research。SOA是用于應用程序之間的基于XML的通信的遠大協議規范。SOAP的目標是通過為復雜的Web服務創建結構良好的基礎來解決RPC，XML-RPC的一些實際缺點。實際上，這只是意味著向XML添加行為類型系統。遺憾的是，它造成的障礙比它解決的更多，因為今天寫的新SOAP端點非常少。

雖然令人難以忍受的冗長和可怕的名字，但SOAP確實有一些好處。客戶端和服務器之間的WSDL和WADL（中的可執行合同保證了可預測的，類型安全的結果，并且WSDL可用于生成文檔或創建與IDE和其他工具的集成。

關于API演變的SOAP的重大啟示是它逐漸且可能無意中引入了更多面向資源的調用。SOAP端點允許你以預定的結構請求數據，而不是考慮生成數據所需的方法（。

SOAP最重要的缺點是冗長，如果沒有大量的工具，幾乎不可能使用它，需要工具來編寫測試，工具來檢查來自服務器的響應以及工具來解析所有數據。許多舊系統仍然使用SOAP，但是對于大多數新項目來說，工具的需求使得它太麻煩，并且XML結構所需的字節數使其成為服務移動設備或分布式系統的不良選擇。

最后，API設計模式：REST。

SOAP使用HTTP作為傳輸，并在請求和響應主體中構建其結構。另一方面，REST拋出客戶端 - 服務器契約，工具，XML，用HTTPs語義替換它們，因為它是結構選擇而不是使用HTTP謂詞與引用某個層次結構中的資源的數據和URI交互數據。

REST完全明確地將API設計從建模交互更改為簡單地對域的數據建模。在使用REST API時完全面向資源，不再需要知道或關心檢索給定數據所需的內容，也不需要了解后端服務的實現。

簡化不僅對開發人員來說是一個好消息，而且由于URL代表穩定的信息，它很容易緩存，它的無狀態使得水平擴展變得容易，并且由于它模擬數據而不是預測消費者需求，因此可以大大減少API的表面積。

REST的發展是目前最值得我們追求的，它是一個驚人的成功，當然它也有自己的缺點。

REST服務往往至少有點“健談”，因為它需要在客戶端和服務器之間進行多次往返才能獲得足夠的數據來呈現應用程序，這種級聯請求會對性能造成破壞性影響，特別是在移動設備上。

REST風格服務的下一個問題是發送方式的信息比需要的多。

REST API缺少的最后一個是內省機制。如果沒有任何關于端點返回類型或結構的信息的合同，就無法可靠地生成文檔，創建工具或與數據交互。

每種API類型都存在缺陷，但是隨著互聯網開發的發展，都在不斷追求完美