企业内部的API

也许还有不少人不太了解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的更改提供有效建议，这些原则一样适用于企业内部。