公共API外包管理是指聘请一个专家小组来解决可扩展性问题，同时也提出几套可替代的方案。

当开发一种新产品或者服务时，公共API的扩散速度会快得惊人。然而，在使用这种丰富资源的同时，工作人员仍心存顾虑。他们在思考，企业是不是有点过于依赖特定的API？它能打破过去的使用权限吗？发布的API又是怎么回事？现有设施的容量是否足够大？

本文是探讨与API管理相关的产品和服务系列文章的开篇之作。其中包括，追踪第三方使用API的路径，并记录下第三方是如何使用API的。

公共API的价值

过去，IT部门只需专注于产品发布就足够了。产品是否适合企业内部使用或者是否可作为一种解决方案供外部客户使用，这些都不重要。产品终端类似于黑箱子，用户仅仅能通过预先设定好的界面来操作产品终端。

如今编码人员越来越多，他们也可以共享各自的代码。首先，通过共享可以建立代码重用函数库，然后，将演变成社区运转项目的协作模式。这种改变需要时间积累。2005年，Google Map的开发人员Paul Rademacher研制了一种逆向工程，并使用私有API建立新款专属应用程序，在个人地图中绘制Craigslist列表。这种做法被公认为网络领域的首例混搭程式（mashup），是历史上公用API 领域内一个重要的事件点。

首例混搭程式揭开了隐藏于开发人员内心的一种渴望，他们想拆解并利用任何现有应用中可用的大小部件。这些应用的主人瞬间意识到，即使目前这些API货币化路径还不明确，提供公共API也可以为提高市场占有率争取一个机会。

要想使某种产品或者服务在Web上可用，最好的方法就是共享API。公共API需要实现三个目标：

1. 显示多功能性。公共API表明，企业并不相信供应商依赖效应，或者不相信消费者在使用服务进行互动时会被欺骗。
2. 信守承诺。好的API在一开始就要展示出产品的核心服务。向客户说明，其架构设计并非只限于当今，在未来的工作中也照常使用。
3. 可以开发新的产品使用途径。客户不仅只是客户，他们同样也可能成为业务的合作伙伴。

尽管我们可以很容易地理解公共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管理方案更合适。