企業內部的API

也許還有不少人不太瞭解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仍很是活躍。如今回顧這一歷程才發現，咱們已經完成了一個輪迴，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.微服務：以應用程序爲中心，以大規模可伸縮且徹底獨立的方式爲應用程序賦予特定的功能。馬丁•福勒(Martin Fowler)和詹姆斯•劉易斯(James Lewis)在其文章中就對此進行了很好的解釋。

實際上，沒有任何證據可以證實在技術層面上，這三個「定義」指的是服務的這一種或者另外一種，雖然有一些特定的要求可能致使一種技術成爲實現某一種定義服務的經常使用方法，可是任何服務均可以經過可用的技術實現。

咱們再次回到本文的主題：企業內部的API。現在，咱們能夠看到一些公司採用了一些概念和技術，這些概念和技術使得API做爲企業內的業務構造很是流行。

觀察這種趨勢最好的方法就是，檢查舊式SOA計劃進展中的成功與不足的方面，並查看以消費者爲中心的技術和思想的應用程序是如何改進這些方面。如今，讓咱們再瞭解一下企業爲何但願在其內部使用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的更改提供有效建議，這些原則一樣適用於企業內部。