公共API外包管理是指聘請一個專家小組來解決可擴展性問題，同時也提出幾套可替代的方案。
當開發一種新產品或者服務時，公共API的擴散速度會快得驚人。然而，在使用這種豐富資源的同時，工作人員仍心存顧慮。他們在思考，企業是不是有點過于依賴特定的API？它能打破過去的使用權限嗎？發布的API又是怎么回事？現有設施的容量是否足夠大？
本文是探討與API管理相關的產品和服務系列文章的開篇之作。其中包括，追蹤第三方使用API的路徑，并記錄下第三方是如何使用API的。
公共API的價值 過去，IT部門只需專注于產品發布就足夠了。產品是否適合企業內部使用或者是否可作為一種解決方案供外部客戶使用，這些都不重要。產品終端類似于黑箱子，用戶僅僅能通過預先設定好的界面來操作產品終端。
如今編碼人員越來越多，他們也可以共享各自的代碼。首先，通過共享可以建立代碼重用函數庫，然后，將演變成社區運轉項目的協作模式。這種改變需要時間積累。
2005年，Google Map的開發人員Paul Rademacher研制了一種逆向工程，并使用私有API建立新款專屬應用程序，在個人地圖中繪制Craigslist列表。這種做法被公認為網絡領域的首例混搭程式（mashup），是歷史上公用API 領域內一個重要的事件點。 首例混搭程式揭開了隱藏于開發人員內心的一種渴望，他們想拆解并利用任何現有應用中可用的大小部件。這些應用的主人瞬間意識到，即使目前這些API貨幣化路徑還不明確，提供公共API也可以為提高市場占有率爭取一個機會。
要想使某種產品或者服務在Web上可用，最好的方法就是共享API。公共API需要實現三個目標：
顯示多功能性。公共API表明，企業并不相信供應商依賴效應，或者不相信消費者在使用服務進行互動時會被欺騙。
信守承諾。好的API在一開始就要展示出產品的核心服務。向客戶說明，其架構設計并非只限于當今，在未來的工作中也照常使用。
可以開發新的產品使用途徑?？蛻舨粌H只是客戶，他們同樣也可能成為業務的合作伙伴。
盡管我們可以很容易地理解公共API為什么可以成為一個成功的觀點，但是，從時間投入和資源利用的角度要想證明，順利構建一個API卻并非一件容易的事情。添加API就如增加一種全新的產品一樣。畢竟，界面、設計、和測試需求都和以前完全不同。這款產品的用戶群也完全不同。
盡管用戶也許很快就適應了應用用戶界面的變化，但是，開發人員一時卻無法接受API中的變化以及所出現的故障。公共API同樣需要額外的監控，以確保他們不會給應用程安全帶來威脅。
解決API管理問題
有許多方法可以解決API管理問題，包括外包API管理。為什么要外包API呢？大部分外包工作都出于以下幾個原因：
沒有可用的內部專業工具。我們應該使用SOAP、REST或者XML、JSON嗎？記住，用戶的API就是開發人員，要根據用戶的特殊要求，建立一組特殊的客戶群體。同樣專業技術專家也很重要。當API準備打入市場，并實行貨幣化時，專業人士的寶貴經驗是非常有幫助的。
API并不存在基礎設施。例如，一個托管應用有10,000個用戶。在使用公共API后，用戶量成功地增長了10倍，系統突然變得超負荷運作。API管理服務有助于解決可擴展問題，同時也可以提供幾套特有的解決方案。
Mashery是最原始的、最成功的API外包服務之一。在去年Intel被收購之前，它給許多企業用戶留下了深刻的印象，包括紐約時報、福布斯、ESPN以及思科。這些企業，在IT預算方面業績非常突出，但是，他們也清楚地明白他們需要API的協助。該商業案例就足以證明這一點了。
如果實施徹底的外包API并未見成效，那么就應該考慮其他混合策略了。這些服務通過云服務可以起到監控作用，保證API的安全性（或許甚至會增加一些計費能力）。這樣就能托管潛在API，并進行實時監控。
外包API方案不能適應某些工作？在下一步安裝過程中，我首先要看一下內部方案，然后API市場營銷和發布方案，并對此進行一次總結，評定出哪種API管理方案更合適。
京公網安備 11010502049343號