我们可以推断，亚马逊的一些成功是来来自于其首席执行官杰夫?贝佐斯十年前宣布的API策略。

你是否在内部使用API？在2003年工员通知中，亚马逊CEO杰夫?贝索斯发布这些逐客令(亚马逊一名前雇员回忆，因其简洁性，作了修改):

• 所有团队从此要通过服务接口发布他们的数据和功能
• 团队之间必须使用这些接口进行沟通。
• 不允许其它的进程通信。唯一允许的通信是使用网络中调用的服务接口。
• 所有服务接口，没有意外的话，必须从头开始设计并外部化。也就是说，团队必须计划并设计能够向外部世
• 开发人员公开的接口，无一例外。

十年前，亚马逊就已经是一家庞大的公司，市值为72亿美元。截至2014年1月，这一数字增加到1830亿美元。当然，并非所有的成功都要归于公共API。然而，API是亚马逊在基础设施和云服务领域占有统治地位的基础。

开发API策略的考虑因素

如果其它公司的CEO复制、粘贴了贝佐斯的模式，是否也能在十年内增长25倍？很不幸不会的，但确有几个问题需要思考，什么时候起草API策略。

第一件需要了解的事情是，API策略并不是必要的产品策略。虽然亚马逊最终能够利用它庞大的基础设施做为新收入来源的基础，他们最初的目的是使公司在高速发展中构建的系统更具有可伸缩性和可维护性。贝佐斯只在最后一条中谈到了服务必须要扩展。明显的迫切需要是减少架构复杂性和集成黑客。教训是，在关注外部API使用前，把内部API使用做为首要任务。换句话说，吃你自己的狗粮。

看这一问题的另一种方法是，认识到大多数面向外部API补充或支持现有的应用程序。Ebay的为了散装产品清单的API，和Netflix的电影发现API（可悲的是，在计划退出）是两主要的例子。他们扩展了服务的主要功能，而不是暴露根本性的新产品。

在亚马逊的进一步对比中，我认识到大多数公司不是初创企业。这些公司已经有了成熟的商业模式，这可能是由在一个漫长的时期建立的数百或数千个应用程序支持的。决定把资源转移到一个基于服务的架构上，将造成巨大的时间和成本影响。让所有服务外部化的概念并不是对所有行业都现实。安全与保密性因素正篡夺公共API的概念。

如果组织已经有大量的应用要维护，并有某些专有或机密数据要保护，那么关于API的当前讨论是否应该忽略？是的，但只有当重新发明轮子、开发脆弱集成和不必要的拖延开发时间时。

公司不会全体都重新设计其整个应用投资组合，但当一个系统需要修正或改进时，把这作为一个机会，问问下面的问题:

• 信息是否暴露了其它地方面可用的数据的复本/子集/父集？是否具有规范的系统记录？如果有，是否有办法公开这些信息，以一种更普遍的、更安全，同时可能会简化内部环境的方法？可能没有立即消化的欲望，但如果没有现成的API，就没有人会采用。
• 系统是否满足了客户信息的需求？如果人们把数据与其它来源的信息结合，那么应用程序可能就是“转椅”集成的一个附件。减少工作和潜在的人为错误足以证明需要创建新的API。
• 客户是如何消化数据的？应用程序可能有一个胖或瘦客户机、转储数据到数据库，或创建文件后由不同的系统传输和解析。这是否将创建出基础设施或协议的依赖？它是否限制了灵活性？信息是否可以用更易访问，从而促进快速原型的创建？

API是最近受到了很多的关注，这是一件好事。API本身并不总是最终产品。最先成为内部消化者，即吃自己的狗粮，可能并不会使用公司成为下一个亚马逊，但却可以帮助减少风险和复杂性。这把公司放到了一个有利的位置，应该决定把基础设施暴露的部分外部化。