我們想透過檢視過去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型別都存在缺陷，但是隨著網際網路開發的發展，都在不斷追求完美
我們想透過檢視過去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型別都存在缺陷，但是隨著網際網路開發的發展，都在不斷追求完美