SOA爲API管理奠定基礎：
在過去十年時間裏， 許多公司爲了達到重用和一致性的目 從而通過分解功能成一個一個原子的服務，在某種程度上實現了SOA。
SOA的目的是於交付流線型的流程,提高效率並且降低成本. 但是 在真實企業得到應用中幾乎很少實施SOA的冬季完成了這一美好的願景。
SOA有好的抱負但是用了錯誤的方法. SOA最初的目的-能重用服務、提供應用的可伸縮性可擴展性並且允許互操作z在服務於應用之間,這才正是業務想要的。 問題 在於 在真實的實施過程中。企業採取一種至上而下的方式不正確的架構他們的SOA項目 從而導致許多問題。 "至上而下"的方法即“推翻重來”的策略它的目的是階段性的替換已經運行很多的企業系統用先進的技術。因爲這些老系統往往已經運行很幾天，所以在改造過程中需要耗費很長的時間是乃至很多年 ，在這過程中花費了巨大的財力和其他資源。最後 還是企業爲SOA這個昂貴的負擔買單。這是使得SOA一度將近被遺棄的最主要的原因之一。整個業界於是對於SOA都報以負面的言論。由於採用至上而下的方式導致花費鉅額金飛並且最後失敗去產生業務價值，SOA實質上已經被認爲已經死掉了。 然而， SOA的基本原則還是合理的，通過API管理賦予了SOA新的生命。
下一代SOA: API管理
API管理實質上是下一代SOA。 但是 API管理應該怎麼的規避以前SOA實施過程中的未必SOA動機的陷阱呢？ 雖然 API管理也具有很多公共的特性和SOA， 他們之間也有不同點 主要表現在了兩個方面。
第一： API管理採用“從底向上”,封裝&更新 的方式 而不是 使用 "至頂而下" 全盤推翻的方式。API（s）通過對訪問和開發者友好的接口進行分層進而給services注入了新的生命。對於服務消費者而言有效的屏蔽了底層技術實現.
第二： API的動機是圍繞投資回報率(ROI)，相互定義了各個里程碑保證迅速實現。可以立即才生效一併且可以對ROI進行衡量。
這個方法不僅僅能夠達到SOA的最初承諾 並且 還具有一下幾個有點：
縮短應用程序開發時間
減少失敗的奉獻
提供開發員的效率
敏捷 可伸縮
SOA和API管理都遵循的核心原則：
業務邏輯抽象
穩固/健壯的管理架構
重用服務
什麼是API ?
API可以有多種定義方式~ 事實上 有一些朋友認爲API 和服務是可以互換的兩個概念。 然後 另外一些朋友則認爲他們是兩個完全是不同的 . 在繼續討論之前讓我們建立一個統一的定義關於API。 簡而言之 ,API(Appliation Programing Interface)提供程序員了一種方式去交互/消費服務。爲了更好的理解讓我們以一個類比的例子來理解： 假設我們每天都在使用的"電"就是一個服務. 公共事業公司通過插座提供了一個服務(電)給每天的廣大市民。只有具有相同型號插頭的客戶才能使用這個服務(電)通過這個插座. 在這裏就出現了三個事物：
電--- 服務
插座-- API
插頭 -- 消費者
只有具有相同型號的插座（抽象的講 就是具有一定的訪問權限）才能訪問這個服務. 此外，消費者（插頭）可以利用消費的服務(電)實現自己的服務通過他們自己的方式. 比如一個筆記本電腦，它通過插座供電(消耗電)。 通過它自己的”API“ （筆記本電腦的某些模塊） 比如一個USB的插口(API).它也能夠提供服務(電)給其他充電設備比如手機，相機等。
實施API管理的後驅力量
著名美國諮詢公司高納德諮詢公司預言到2014年75%的財富500強企業都將開放交互式OPEN。在當前新的API經濟時代，沒有開發API戰略的公司將落後。企業都漸漸意識到開發API(s)的重要性以及API所交付給業務的價值。 具體的體現如下幾點：
業務敏捷性: 更高效的暴露一個業務邏輯做爲了API比創建一個業務邏輯並且呈現它在一個網站上。消費者可以通過他們自己喜歡的方式去消費這個API不必去訪問網站。這樣也提供客戶更多的方式去進行系統集成.
API經濟: 商業公司正在開發“API產品”作爲新的利潤來源. Expedia獲得了200萬的年度利潤通過使用API。 Salseforce 75%的利潤來自於API。
物聯網：可互聯設備數量不斷增加.可以通過API進行設備將的互相訪問.
既然我們定義好了什麼是API 以及API和服務之間的關係。 是時候來驅動探究
高效API管理的七個最佳實踐。
Habit1： 應用API先行設計的方法
這裏就簡單的列舉API設計先行的步驟
典型的,業務負責人識別一個業務需求
然後業務負責人將和架構師(設計師)一起設計這個業務需求的API，並且編制API的說明文檔
一旦API說明文檔完成以後,架構師將通過說明文檔和後端程序開發團隊溝通，由開發團隊負責完整API的後端邏輯實現.
![wKiom1NrqzeAOljbAAHtoGQ6JiM794.jpg]( "QQ截圖20140509000051.png")
Habit2: 選擇一個穩定強大的API運行環境
當前流行很多ESB運行環境比如IBM的或者開源的Mule， Mule也有企業版本提供更多的管理/部署/安全機制. 這裏我們討論從以下幾個方面來選擇一個好的運行平臺。
多平臺支持:現在越來越多的業務正在轉移到雲端. 這裏就顯得尤爲的重要對於跨平臺支持. 選擇的平臺需要運行你的API能夠遷移到雲端服務器 或者 能夠順利部署到企業內部其他預置環境 不需要做任何改動。
可擴展性/可靠性/可用性: 這三面的考量因素都非常至關重要在選擇一個運行平臺時.
強的API/實現分離以及業務流程編制能力: 運行環境應該有能力去執行一個複雜的後端業務規則編制能力,
Habit3:建立一個集中服務庫
開發了這麼API， 我們也需要讓我們的的當前的或者潛在的客戶能夠發現和訪問我們這些API. 因此 我們需要一個集中的服務庫提供一個APIs查詢途徑. 可以通過建立專題/論壇 和編寫詳細的文檔.這樣開發者可以很容易去評估一個API是否合適並且迅速的集成進入他們的系統通過我們暴露的API。此外， 架構師和業務負責人也可以很清楚的看到那些API正在服務 並且做出正確的決定 以及不斷加強API在未來的版本中。
Habit4:通過版本/策略/契約 管理服務
跟蹤服務版本和消費者,從而給出業務視圖展現誰在使用API,正在使用那個版本.這有助於管理API的聲明週期 並且允許API發佈者去評估影響當要決定關閉一個服務的時候。
此外，安全也是非常重要的一個方面。 需要制定策略去強制執行安全以及刮泥SLA(服務級別協議)和API消費者。 一個好的API運行平臺應該提供一個容易的方式去創建安全策略和契約。
Habit5:推銷以及建立社交平臺爲你的API(s)
前面habit3提及到了需要建立一個服務庫, 這裏我們也需要見一個開發者門戶，提供給開發者和服務提供者、開發者之間的交流平臺。 開發者可以容易的注意到我們的API的發佈以及下載文檔和提出問題和意見。
Habit6: 監控和評估API的使用
明白那寫service正在被使用是非常重要的。 就關注還不夠， 你也需要知道這些API是以那些方式被消費的。 通過整體使用情況和每個用戶的使用情況 ，企業可以容易的監控API的活動. 從技術和業務願景去監控API的使用情況是非常有價值的。 這樣可以幫助業務負責人和技術團隊更好的理解他們的用戶並且創建更好的服務。
Habit7: 持續改進服務
迭代habit1-habit6不斷持續的改進