也许还有很多人不太了解API，简单来说，API就是实现两个网站或者数据库之间通过互联网通讯的接口代码。例如，一家在线电影租赁网站希望与Facebook合作，让你的Facebook好友能随时知道你浏览过的影片。而在没有API的时代，实现这个功能需要在线电影租赁网站把你每天浏览过的电影制成列表，通过Excel文件格式发给Facebook。可以想象，这个过程是多么缓慢且容易出错。有了API，在线电影租赁网站就能将这个流程完全自动化，在核实Facebook的对应帐号后，网站的API就能向Facebook实时发送他们感兴趣的账户相关数据。
如今API在企业内部也得到大量普及，尤其是部分公司随着业务的发展，规模会日益扩大，公司的业务也会越来越丰富，公司内部的部门也会越来越多，不同的业务将会由不同的部门来负责，每个部门都有自己的一亩三分地。同时，公司的每个部门或多或少会将一些能力对外开放，然而这些能力都会以API的形式提供给外部。
截止到目前，软件行业普及“API”也已经有几年了，“API”通常指的是作为技术服务公开给开发人员使用的业务功能。与以前通常由企业架构团队来制定正规的IT架构和SOA治理实践驱动的繁重任务相比，更灵活、轻量地使用API来提供业务能力是一个巨大的理念跃迁。
2009年，Gartner集团的Anne Thomas-Manes高调的宣称“SOA已死”，尽管在市场上表现的形式有所不同，但实际上SOA仍非常活跃。现在回顾这一历程才发现，我们已经完成了一个轮回，API正在迅速成为企业实现SOA优势的一种方式。
几年前，行业的大部分人认为API只是Web服务的别称，因此提出了各种关于REST与SOAP，JSON与XML等的争论。如今，这种说法已被人们广泛接受，开发者不再注重协议的特殊性，而是更关注API如何满足广泛业务的需求。虽然最初使用术语“API”意味着RESTful服务，但在过去几年中，实用主义已经胜过纯粹主义，因此尽管大多数API使用HTTP作为传输，但纯粹的RESTful服务只占小部分。大多数人现在都接受 “API”可以指代多种协议，例如HTTP、AMQP、JMS上的服务，这些协议具有广泛的交换模式（RESTful，RPC，同步，异步）以及广泛的内容形式，最常见的仍然是JSON，XML和特定的XML变体，如SOAP，Accord，HL7等。
不过，API除了是服务的一项别称之外，更是一种技术立场。不同类型的服务之间存在一定的区别，可以将服务分成三个部分(也许未来会更多)：
1.SOA服务(通常是SOAP)：以提供者为中心，通常以“如果我构建它，它就会出现”的思路进行，目的就是通过促进资产重用来减少IT开销；
2.APIs (通常是REST/JSON)：以消费者为中心，通常以产品管理方法驱动，目标是通过与合作伙伴及外部开发人员共享业务功能以驱动新的业务机会；
3.微服务：以应用程序为中心，以大规模可伸缩且完全独立的方式为应用程序赋予特定的功能。马丁•福勒(Martin Fowler)和詹姆斯•刘易斯(James Lewis)在其文章中就对此进行了很好的解释。
实际上，没有任何证据能够证明在技术层面上，这三个“定义”指的是服务的这一种或者另一种，虽然有一些特定的要求可能导致一种技术成为实现某一种定义服务的常用方法，但是任何服务都可以通过可用的技术实现。
我们再次回到本文的主题：企业内部的API。如今，我们可以看到一些公司采用了一些概念和技术，这些概念和技术使得API作为企业内的业务构造非常流行。
观察这种趋势最好的方法就是，检查旧式SOA计划进展中的成功与不足的方面，并查看以消费者为中心的技术和思想的应用程序是如何改进这些方面。现在，让我们再了解一下企业为什么希望在其内部使用API。换句话说，让我们重温一下SOA背后一些令人激动的元素，这一次采用更现代的实现方法:
1）成本和时间效率
公司的IT部门开展SOA活动的主要原因之一是，通过提供应用程序团队可以利用的共享资产(业务服务)库，最大限度的减少一些重复工作，避免不断重新发明轮子。 但是SOA批评者经常指出这些计划未能真正起到重用，特别是与实现这些计划的重要流程和基础架构相比。SOA计划没有兑现承诺的原因有很多，部分与技术有关，但无论成败结果如何，通过良好管理的重用程序以实现节省成本和时间的承诺不容忽视。
也许通过将以现代消费者和应用程序为中心的概念与IT驱动的以提供商为中心的理念相结合，公司就可以有意识地挖掘这一潜力，通过使用现有服务而不是每次从头开始构建所有内容，使新的应用程序开发更快、更便宜。
2）数据的一致性
每当开发人员在不同的应用程序中构建相同的功能时，都有得到不同结果的风险。举一个简单且很常见的客户数据库示例：每家公司至少有一个管理所有客户的数据库，但每次出现新的应用程序时，设计师都认为现有的客户数据库不适合他们的需要，所以他们会建立一个新的数据库，有时会尝试同步数据，有时会从头开始。如果可以轻松扩展数据事实来源以满足新应用程序的要求，公司就只需在一个位置不断更新数据，客户便可以轻松地访问并合并信息。
这里的挑战有两个方面:
1.说服新的应用程序开发人员，告诉他们现有的服务足以满足需求；
2.足够迅速地扩展现有服务以满足不断变化的需求
3）应用程序组合合理化
技术可能会过时，但永远不会消失。大型机就是一个典型的例子，在接近千年虫的几个月里，我们都相信将见证大型机的终结，然而奇怪的是现在几乎每个大型企业在大型机上的花费都与上世纪90年代持平，甚至更多。
部分原因是替换旧的应用程序会比较困难。系统开始依赖它们，并使用高度专有的机制与它们集成，因此再很难替换核心系统。ESB(企业服务总线)背后的最初意图就是通过在消费应用程序和后端应用程序之间放置一个服务层来抽象后端实现。尽管与许多SOA计划一样，ESB在操作和管理上变得过于复杂，并且成为遗留系统，就像它们被设计成为抽象的后端应用程序一样。
我们现在看到的结果是，更多的后端系统正在呈现基于标准的接口(服务)，这些接口可以很容易地被现代应用程序使用，从而减少了直接依赖关系，使得替换(或至少使原始应用程序现代化)变得更容易。这其中的奥秘就是让开发人员更容易的使用这些服务，而不是直接与后端集成。
4）治理
关于“治理”就变得有些棘手了。许多开发人员和架构师在听到“治理”这个词时都会感到害怕，但是对于企业架构师和CIO来说，治理却有很多价值。治理变得失控是一件糟糕的事情，它使得所有的SOA活动都失败，如何有效的治理程序决定着成功和失败，其核心就是有效的治理程序可以帮助大家构建正确的服务，并正确地运行它们。
治理不仅适用于SOA计划，也同样适用于API计划。随着企业开始使用API，就必须要确保正确地管理API扩散。在外部API活动中，公司让产品经理负责他们的API，并为新的API构建以及对API的更改提供有效建议，这些原则同样适用于企业内部。