也許還有很多人不太了解API，簡單來說，API就是實現兩個網站或者數據庫之間通過互聯網通訊的接口代碼。例如，一家在線電影租賃網站希望與Facebook合作，讓你的Facebook好友能隨時知道你瀏覽過的影片。而在沒有API的時代，實現這個功能需要在線電影租賃網站把你每天瀏覽過的電影制成列表，通過Excel文件格式發給Facebook。可以想象，這個過程是多么緩慢且容易出錯。有了API，在線電影租賃網站就能將這個流程完全自動化，在核實Facebook的對應帳號后，網站的API就能向Facebook實時發送他們感興趣的賬戶相關數據。

如今API在企業內部也得到大量普及，尤其是部分公司隨著業務的發展，規模會日益擴大，公司的業務也會越來越豐富，公司內部的部門也會越來越多，不同的業務將會由不同的部門來負責，每個部門都有自己的一畝三分地。同時，公司的每個部門或多或少會將一些能力對外開放，然而這些能力都會以API的形式提供給外部。

截止到目前，軟件行業普及“API”也已經有幾年了，“API”通常指的是作為技術服務公開給開發人員使用的業務功能。與以前通常由企業架構團隊來制定正規的IT架構和SOA治理實踐驅動的繁重任務相比，更靈活、輕量地使用API來提供業務能力是一個巨大的理念躍遷。

2009年，Gartner集團的Anne Thomas-Manes高調的宣稱“SOA已死”，盡管在市場上表現的形式有所不同，但實際上SOA仍非?；钴S?，F在回顧這一歷程才發現，我們已經完成了一個輪回，API正在迅速成為企業實現SOA優勢的一種方式。

幾年前，行業的大部分人認為API只是Web服務的別稱，因此提出了各種關于REST與SOAP，JSON與XML等的爭論。如今，這種說法已被人們廣泛接受，開發者不再注重協議的特殊性，而是更關注API如何滿足廣泛業務的需求。雖然最初使用術語“API”意味著RESTful服務，但在過去幾年中，實用主義已經勝過純粹主義，因此盡管大多數API使用HTTP作為傳輸，但純粹的RESTful服務只占小部分。大多數人現在都接受 “API”可以指代多種協議，例如HTTP、AMQP、JMS上的服務，這些協議具有廣泛的交換模式（RESTful，RPC，同步，異步）以及廣泛的內容形式，最常見的仍然是JSON，XML和特定的XML變體，如SOAP，Accord，HL7等。

不過，API除了是服務的一項別稱之外，更是一種技術立場。不同類型的服務之間存在一定的區別，可以將服務分成三個部分(也許未來會更多)：

1.SOA服務(通常是SOAP)：以提供者為中心，通常以“如果我構建它，它就會出現”的思路進行，目的就是通過促進資產重用來減少IT開銷；

2.APIs (通常是REST/JSON)：以消費者為中心，通常以產品管理方法驅動，目標是通過與合作伙伴及外部開發人員共享業務功能以驅動新的業務機會；

3.微服務：以應用程序為中心，以大規?？缮炜s且完全獨立的方式為應用程序賦予特定的功能。馬丁?福勒(Martin Fowler)和詹姆斯?劉易斯(James Lewis)在其文章中就對此進行了很好的解釋。

實際上，沒有任何證據能夠證明在技術層面上，這三個“定義”指的是服務的這一種或者另一種，雖然有一些特定的要求可能導致一種技術成為實現某一種定義服務的常用方法，但是任何服務都可以通過可用的技術實現。

我們再次回到本文的主題：企業內部的API。如今，我們可以看到一些公司采用了一些概念和技術，這些概念和技術使得API作為企業內的業務構造非常流行。

觀察這種趨勢最好的方法就是，檢查舊式SOA計劃進展中的成功與不足的方面，并查看以消費者為中心的技術和思想的應用程序是如何改進這些方面?，F在，讓我們再了解一下企業為什么希望在其內部使用API。換句話說，讓我們重溫一下SOA背后一些令人激動的元素，這一次采用更現代的實現方法:

1）成本和時間效率

公司的IT部門開展SOA活動的主要原因之一是，通過提供應用程序團隊可以利用的共享資產(業務服務)庫，最大限度的減少一些重復工作，避免不斷重新發明輪子。 但是SOA批評者經常指出這些計劃未能真正起到重用，特別是與實現這些計劃的重要流程和基礎架構相比。SOA計劃沒有兌現承諾的原因有很多，部分與技術有關，但無論成敗結果如何，通過良好管理的重用程序以實現節省成本和時間的承諾不容忽視。

也許通過將以現代消費者和應用程序為中心的概念與IT驅動的以提供商為中心的理念相結合，公司就可以有意識地挖掘這一潛力，通過使用現有服務而不是每次從頭開始構建所有內容，使新的應用程序開發更快、更便宜。

2）數據的一致性

每當開發人員在不同的應用程序中構建相同的功能時，都有得到不同結果的風險。舉一個簡單且很常見的客戶數據庫示例：每家公司至少有一個管理所有客戶的數據庫，但每次出現新的應用程序時，設計師都認為現有的客戶數據庫不適合他們的需要，所以他們會建立一個新的數據庫，有時會嘗試同步數據，有時會從頭開始。如果可以輕松擴展數據事實來源以滿足新應用程序的要求，公司就只需在一個位置不斷更新數據，客戶便可以輕松地訪問并合并信息。

這里的挑戰有兩個方面:

1.說服新的應用程序開發人員，告訴他們現有的服務足以滿足需求；

2.足夠迅速地擴展現有服務以滿足不斷變化的需求

3）應用程序組合合理化

技術可能會過時，但永遠不會消失。大型機就是一個典型的例子，在接近千年蟲的幾個月里，我們都相信將見證大型機的終結，然而奇怪的是現在幾乎每個大型企業在大型機上的花費都與上世紀90年代持平，甚至更多。

部分原因是替換舊的應用程序會比較困難。系統開始依賴它們，并使用高度專有的機制與它們集成，因此再很難替換核心系統。ESB(企業服務總線)背后的最初意圖就是通過在消費應用程序和后端應用程序之間放置一個服務層來抽象后端實現。盡管與許多SOA計劃一樣，ESB在操作和管理上變得過于復雜，并且成為遺留系統，就像它們被設計成為抽象的后端應用程序一樣。

我們現在看到的結果是，更多的后端系統正在呈現基于標準的接口(服務)，這些接口可以很容易地被現代應用程序使用，從而減少了直接依賴關系，使得替換(或至少使原始應用程序現代化)變得更容易。這其中的奧秘就是讓開發人員更容易的使用這些服務，而不是直接與后端集成。

4）治理

關于“治理”就變得有些棘手了。許多開發人員和架構師在聽到“治理”這個詞時都會感到害怕，但是對于企業架構師和CIO來說，治理卻有很多價值。治理變得失控是一件糟糕的事情，它使得所有的SOA活動都失敗，如何有效的治理程序決定著成功和失敗，其核心就是有效的治理程序可以幫助大家構建正確的服務，并正確地運行它們。

治理不僅適用于SOA計劃，也同樣適用于API計劃。隨著企業開始使用API，就必須要確保正確地管理API擴散。在外部API活動中，公司讓產品經理負責他們的API，并為新的API構建以及對API的更改提供有效建議，這些原則同樣適用于企業內部。

轉載于:https://juejin.im/post/5cffa208f265da1bd42476ef

總結

以上是生活随笔為你收集整理的企业内部的API的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。