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的后端逻辑实现.
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不断持续的改进