简介

几乎所有企业都有多个应用程序作为其关键数据的记录系统，而且还拥有它们赖以创业的业务功能。因此，一些组织想要不断向其企业内外更广泛的受众揭示这些操作系统中的宝贵资产，我们对此已司空见惯。但是，这需要时间。在本教程中，我们将介绍这项评估的关键阶段，帮助您评估您的企业在此旅程中的位置，分析您可能想要采取哪些行动来让您的集成架构朝着或超越 API 公开的方向发展。

首先，让我们简要介绍一下业务功能公开的历史，然后更详细地分析以下两个最新的概念之间的区别：面向服务的架构 (SOA) 和 Web API。

过去几十年来，整个行业在集成架构上的进化显而易见，业务功能的公开程度不断加大，如图 1 所示。

图 1. 业务功能的渐进式公开业务功能的渐进式公开

我们的目的是了解 SOA 与现代业务 Web API 之间的区别。为了有效地理解此区别，我们需要明确了解 SOA 带来了什么。

让我们简单看看前 3 个阶段（一直到 SOA）发生了哪些变化，然后分析 Web API 增添了哪些变化。

使用 “低级 API” 的点对点连接

自从企业拥有应用程序，就需要在应用程序之间移动和共享数据。让用户在不同系统中反复输入信息（“转椅” 集成）在大多数情况下无助于持续发展。这带来了在孤立的应用程序之间建立直接（点对点）低级连接的需求。获得实时的响应常常是不可能的，所以数据通常是通过文件或单向消息异步发送的。每个接口的每一端都需要新的序列化和解析代码，如图 2 所示。

图 2. 点对点集成点对点集成

应用程序之间的不同连线表明，通常需要多个不同的协议来实现不同的接口，这使集成任务变得更加复杂。

为此，我们引入了应用编程接口 (API) ，包括传输、协议和用于实时交互的数据格式，使直接从被调用的系统获得响应成为现实。当然，这是缩写词 API 的起源，API 现在已拥有称为 “Web API” 的新用途。本教程将明确区分这两种 API，将原始类型称为 “低级 API”，将新类型称为 “Web API”。在日常用语中，Web API 通常被简称为 “API”。

集成的成熟度通常是使用 服务集成成熟度模型 (SIMM) 来度量的。点对点集成的 SIMM 级别通常为 2。SIMM 是一种成熟度模型，但我们应谨慎地理解 “成熟度” 的含义。在您进入下一个级别时，模型中的每个级别上采用的技术不会过时，它们只是被更有选择性地使用。例如，即使在实现了 SIMM 级别为 4 的服务的公司中，仍然可能对偶尔的点对点或中心辐射型集成具有充分合理的需求。

这些低级 API 在不同平台上具有明显的区别，这就需要向每种集成两端的应用程序中写入复杂的特定于应用程序的连接代码。

企业应用程序集成

在上世纪 90 年代，集成工具和运行时变得越来越常见。它们知道如何执行连接，并提供了一个中央集线器来执行所有集成。

这实现了一种更加类似 “中心辐射型” 的架构，并显著减少了编写的专用集成代码量，如图 3 所示。这通常具有 SIMM 级别 3，被称为企业应用程序集成 (EAI)。

图 3. 中心辐射型架构中心辐射型架构

这些新工具和技术意味着，您可以在集成集线器范围内重用连接，您只需要确定如何连接到一个应用程序一次。总是使用同样的工具和运行时来完成此工作，而不是在多种语言和多个平台上使用集成代码。

由于应用程序之间根本不同的交互风格，它们通常没有实时连接。更常见的是，一个入站适配器从系统获取数据并存储在基于文件或消息的存储器中，然后一个集成流处理该数据并将其传递给目标系统。在数据仅需要用于引用用途时，这不可避免地会导致在系统间复制大量数据。与原始系统连接的实时接口（real-time interfaces）可减少这种重复。

渐渐地，与操作系统连接的实时接口变得更加普遍，它们减轻了对跨系统复制数据的需求。但是，一个新系统要使用这些实时接口之一，仍然需要一些工作来将它连接到集线器。诚然，在中心辐射型架构上所做的许多尝试仅仅稍微减轻了点对点问题，向一个运行时和一个工具中引入了点对点编码。除非集成是针对重用而小心设计的，否则创建一个新接口仍然需要大量新代码。

我们需要一种更加标准化的方式来从集线器公开功能，以便无需额外的工作即可重用它。

面向服务的架构

在 2000 年代初，随着传输、协议和数据格式标准得到更广泛的采用，比如 SOAP/HTTP（通常称为 “Web 服务”），以标准化方式公开服务成为可能。这意味着请求者（他们理解这些现代标准）通过最小的努力就可以使用这些服务。这些公开的业务功能的直接重用现在已变为可能。一个经过良好控制的公开服务套件应该具有 SIMM 级别 4。

任何重用机会都会带来新的收益，同时也会带来新的挑战。使用 SOAP/HTTP 简单地公开业务功能，不足以确保服务的健全性。它会带来许多挑战，从系统间难以管理的依赖性到安全暴露。

从服务公开的角度讲，SOA 比协议和数据格式的标准化复杂得多。要有效地公开服务，还需要标准化以下方面：

虚拟化：用户必须调用一个隐藏了其最终的实现方式和位置的复杂性的虚拟 服务端点。向标准化的协议和传输的转换是虚拟化的一部分，但服务还需要提供标准的可配置方面，比如路由和数据转换，同时继续向用户提供同样的虚拟 服务来最小化变更的影响。

可视性：如果公开核心业务功能，您需要管理和监视它们。要大规模地实现有效的监视，需要在所有服务上以一种标准化方式来执行。

安全性：要让服务容易使用且更容易管理，您需要标准化访问控制、身份管理和其他关键的安全性 方面。安全性是复杂的，而您需要您的服务容易使用。您需要减少向用户公开的安全模型的变化。

流量管理：您如何确保高优先级用户始终能够访问他们需要的服务，并获得可接受的响应时间？如果您需要临时牺牲一个用户来留住另一个用户，该怎么办？您如何管理计划或计划外的宕机？您需要对服务公开点执行某种形式的可配置的操作控制，使您无需经历代码周期即可进行调整。

这篇教程的开头已经更详细地描述了这些方面：WebSphere Process Server 和 WebSphere ESB 中的解决方案设计。

要实现上述所有标准化，您需要正式地分离架构中的服务公开功能，如图 4 中的服务公开网关所示。它可能不是最终的物理架构中的一个单独的运行时组件，但至少需要在设计中明确地描绘它。必须可以以一流的方式满足虚拟化、可视性、安全和流量管理需求。

图 4. 服务公开服务公开

您将注意到，我们在图 4 中所示图表中特意未 使用常见的 SOA 相关术语，企业服务总线 (ESB)。这是因为人们对 ESB 的准确界线存在很大的分歧。毕竟，ESB 是一种架构模式，而不是组件描述。有人说，它只是服务公开网关，而其他人认为它包含集成集线器。有人认为它也包含适配器，在这些观点之间还有许多变体。有大量文献描述了 ESB 模式的细节，但我们最终发现，清楚地描述各个具体的组件和它们的职责会更好。

除了 SOA 的运行时组件之外，还有治理方面。如果有大量服务，您如何决定要公开哪些功能和它们的优先级？人们将如何发现所公开的功能？您如何控制所使用的数据模型中的变化？必须保留候选和当前服务的某种形式的目录，以实现服务生命周期的治理。

所有这些担忧最终可归结为，公开服务不是小事。如果只是简单地将功能公开为通用的 Web 服务，则会在可管理性和安全性上带来大量失败机会。简言之，重用具有代价，而且随之而来的是如何找到 SOA 的问题。任何具有紧张的最后期限和预算限制的项目，都不希望成为首次构建某个服务的项目 - 至少不太合适。

除此之外，事实上，人们实现 SOA 概念所需的标准是在 SOA 举措实施过程中不断开发的，因此它们还不够成熟。在企业尝试实现它们的过程中，它们也在不断改变。很容易看到为什么一些 SOA 难以获得发展动力。在许多公司，SOA 被局限在业务的一个特定领域，或者实际上只有少量核心服务在起作用。

JSON/HTTP 接口介绍

基于浏览器的应用程序变得更加复杂，而且引入了一些机制来编写功能更丰富、响应更迅速的网页。这些机制利用了浏览器愈加成熟的客户端脚本功能，以及它们使用 AJAX 等技术执行后台 HTTP 请求来检索数据的能力，而且用户体验不会被页面预加载中断。

网页通常通过页面关联的 Web 服务器来请求特定于网页的数据。SOA 中常见的 SOAP/HTTP 请求在 JavaScript 中很难处理，而且请求的发送常常使带宽很低的 Internet 连接变得不堪重负。执行更细粒度的数据请求正快速变得流行起来，如果可能的话，可以更改为使用 JavaScript 原生的 JSON 数据格式，如图 5 中的红色区域所示。

图 5. 富浏览器应用程序的细粒度公开富浏览器应用程序的细粒度公开

由于不受 SOAP 标准的限制，这些接口可被视为简化在要表示的数据上执行 “动作” 或 “操作” 的方式的备用方式。在一次对 Web 早期根源的有趣的回溯中，HTTP 背后最初的意图被揭示了出来。HTTP 标准的许多方面是围绕 Roy Fielding 在 2000 年 提交的具象状态传输 (REST) 的架构原则而设计的。由此衍生出了一种基于实体的更加简单化的交互风格。该交互风格推荐以一种与常见数据库交互洞察（创建、请求、更新、删除）类似的方式，使用常见的 HTTP 洞察（POST、GET、PUT、DELETE）。全球网络以一流的方式识别这些洞察，以提供隐含的好处，比如缓存。它还使用 URL 路径来导航数据实体之间的关系。

在一个更加简化的示例中，可以想象向一个订单添加一个商品的过程，可通过向一个 URL 发出 HTTP “POST” 来执行此操作，这个 URL 类似于下面这个 URL：

https://www.mycompany.com/orders/123456/item

HTTP 请求正文中的 JSON 格式数据类似于如下形式：

{ "title" : "Romeo and Juliet",
   "note" " "Special Edition",
   "quantity : 1,
   "price" : 9.99 } 

其中 URL 描述了特定的数据实体（通常称为 “资源”），HTTP 动词 “POST” 的使用意味着它是一个新订单项的 “创建” 操作。要在 SOAP 中承载同样的信息，代码更类似于如下形式：

http://www.example.org/ordermanagement HTTP/1.1
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://..." soap:encodingStyle="http://...">
  ...SOAP headers...
  <soap:Body xmlns:m="http://www.example.org/ordermanagement">
    <m:AddOrderItem>
      <m:order orderid="123456"
        <m:item>
          <m:title>Romeo and Juliet</m:title>
          <m:note>Special Edition</m:note>
          <m:quantity>1</m:quantity>
          <m:price>9.99</m:price>
        </m:item>
      </m:order>
    </m:AddOrderItem>
  </soap:Body>
</soap:Envelope> 

与之前出现的越来越复杂的 SOAP 标准相比，这些基于 JSON/HTTP 的接口提供了一些有用的简化。但是，SOAP 拥有更庞大的 标准集合，它们可完成这些接口做不到的许多事情。它们被不同的受众使用，而且不是所有这些标准在该领域都是必要的。

至少在最初，这些新接口的可重用性上存在一些限制。由于浏览器实现的 同源策略，基于网页的应用程序很难（但不是不可能）向其他公司提供的接口发出 HTTP 请求。这意味着，这些基于 JSON/HTTP 的接口最常见的初始用途，是用在公司的网页与其自己的企业数据之间。但是，一些技术（比如代理、JSONP）和标准（比如 CORS）减轻了这些限制，使这些接口能够得到更广泛的重用，使 “Web API” 变成了现实。

什么是 Web API？

对于 “Web API” 的准确含义，没有正式的定义，就像在它之前的 “Web 服务” 一样，但我们会尽量明确它的含义。

大体上讲，“Web API” 通常指通过以下方式公开的功能和数据：

通过 HTTP(S) 公开

以 REST 风格使用 HTTP 协议

使用 JSON 作为数据格式

可通过互联网使用

对于如今任何创建新 Web API 的人，这可能是您的起点。但是，从某些层面上讲，此定义过于简单：

不是所有 Web API 都使用 JSON：大多数 API 都使用 JSON 作为数据格式，但一些 API 提供 XML 作为一种备用格式，或者甚至惟一地使用 XML。在理论上讲，HTTP 可响应的任何请求都是有效的。如果您包含 MIME 类型（举例而言，这可能意味着使用 PDF 文件），这种更广泛的用途不那么常见。

不是所有 Web API 都是公共的：我们在后面的一节中将会看到，API 不仅在公共互联网上公开和使用。但是，可以合理地认为，风格、用法以及受支持产品和协议上的许多一致意见都是互联网用途所推动的。

不是所有 Web API 都直接使用 HTTP 的 REST 风格的特性：有许多面向互联网的 SOAP/HTTP 接口，而且很难否认，这些接口在某种形式上也是 Web API。它们或许不那么 “REST 化”，而且更难使用。但是，许多 SOAP/HTTP 接口随后引入了 JSON/HTTP “REST 风格的” 等效功能。

很少有 Web API 是完全 REST 风格的：在 Web API 中使用 JSON/HTTP，这意味着肯定比以前更加 REST 化。因此，它们通常被称为 “REST” 接口。但是，实际上，大多数接口仅符合 有关该主题的原始材料 中描述的部分 REST 建议。针对自称 REST 化的 API 的一种常见抱怨是，它们很少提供 HATEOS 方法所推荐的链接。

强烈推荐使用 HTTPS：HTTPS 显然是首选的，而且许多人认为是 Web API 的强制要求。有效负载通常包含私有数据，用于访问 Web API 的凭据通常是机密的。

所以出现了一种新的、更加轻型的协议和交互风格，但单单此协议和交互风格无法为向实时数据集成的演化保驾护航。

让 Web API 变得成熟的触发因素是什么？

在 2007 年左右拥有容易访问的 “应用程序” 商店的智能电话成为主流时，业界发生了重大变化。移动应用程序（“app”）开发得以普及，而且庞大的开发人员群体都可以参与开发。除了一些明显的例外，应用程序很少能单独运行。它们需要与周围世界交互。开发人员如果拥有简单的途径来整合对其他公司提供的数据和功能的访问，他们就能够编写强大得多的应用程序。

这不仅是来自移动应用程序开发人员的要求，功能更丰富的网站的开发人员也需要更广泛、更轻松地访问数据。但是，移动通常会带来大量新的 Web API 用户。他们没有安全限制方面的阻碍，这些阻碍给基于浏览器的应用程序中的 API 使用带来了一些挑战。所以，您可以认为，Web API 的引入有两种重要影响：需求和能力。

新的赚钱方式：受（但不仅限于）新一代移动服务使用者的流行所推动的新兴盈利性融资模型，这些使用者表现为电话、平板电脑、手表等的应用程序的形式，都需要访问实时的数据和功能。

成熟的能力：经过十年来在可重用服务公开上的努力，公开业务功能的标准、技术和方法已发展成熟。举例而言，协议和数据格式的公开在不断试验中逐渐成熟。API 的公开网关现在可用作一个一级组件，而且它拥有得到广泛认可的职责范围。

Web API 与之前的 API 有何区别？

正是在新需求及其关联的融资模型中，大数据发挥着重要作用。公开的业务功能的受众位于企业外。如图 6 所示，SOA 服务更常见的是在企业内 公开，一般基于一个项目漏洞和它们各自已知的需求。Web API 通常在外部 向常常未知且可能庞大的用户群公开，通常用于高度创新性和无法预料的用途。

图 6. 影响在企业外公开服务的新因素影响在企业外公开服务的新因素

如果一个 Web API 可提供对一个应用程序有用的数据，那么它对其他应用程序可能也有用。将这些服务（或 API）放在网络上，而且 Web API 突然会获得整个互联网的潜在用户，甚至可到达许多以前无法接触到的细分客户群。这离不开新的融资模型。我们有机会从这些公开的业务功能中牟利。Web API 变成了组织提供的一种新 “产品”。

投资回报可能具有许多不同的形式：

直接收入：例如，一个用于购买商品的 Web API。

间接收入：例如，通过向其他服务商提供聚合服务来赢得佣金。

成本节省：例如，实现自助服务来精减一个昂贵的客户服务的应用程序。

市场营销：例如，将产品信息放在更庞大的客户群面前。

可以肯定的是，通过将应用程序设计师的创新众包到企业外，可获得新的市场。

您如何迎合对您的集成架构的需求的这一重大变化？

这个公开组件对 Web API 有何不同？

基于 Web API 的早期定义，您可以看到，与企业服务相比，在公开外部 Web API 时有 3 个重要方面将发生根本性改变：

超出企业界线：Web API 用户不是企业的一部分，所以他们不受您的直接影响和控制。

无数的用户：您的 API 的潜在用户比企业服务的用户多得多。

竞争性市场：如果您的 Web API 无法满足用户的期望，他们拥有其他公司所提供的替代选择。在拥有 SOA 的企业内，他们可能仅有一个选择。

这些关键的不同会导致您架构和设计 Web API 的方式发生大量的修正。在本教程中，我们主要关注架构的区别。在架构上，您显然仍然需要某种形式的公开网关，但对该网关的需求拥有一些新元素。

回想本教程之前的内容，重用始终是有代价的。从图 7 中可以看出，您的公开能力需要扩展到核心 SOA 需求以外。

图 7. 针对企业外的公开 API 的新能力针对企业外的公开 API 的新能力

我们看看这些新挑战的两个主要方面：

合作伙伴管理：您现在拥有一个庞大的移动应用程序设计师团队，其中的设计师可能想要试验您的 Web API。如果不将它设计得非常容易使用而且具有吸引力，您的 Web API “产品” 很快就会被竞争对手赶超。您如何与这些新合作伙伴建立新关系？您如何持续跟踪谁在访问这些功能？您可能拥有外部相关方依靠您的 Web API 作为其业务的基础部分。您如何建立和监视他们需要何种服务水平？合作伙伴管理必须是 Web API 公开组件提供的一个一级功能。由于潜在合作伙伴的庞大数量，合作伙伴管理必须是自助式的，它还需要识别合作伙伴，依据达成一致的授权计划来监视和控制他们的使用情况。

安全性：显然，通过公共媒介（比如互联网）公开 Web API 意味着需要考虑全新的安全问题水平，从各种以有效负载为载体的攻击，比如 XML 威胁，到对吞吐量或连接的拒绝服务攻击。您还必须可靠地验证您合作伙伴的应用程序，以便有效地控制其服务水平。

这种增加的复杂性导致了现在所谓的 API 管理 的出现。Web API 管理是一种架构意图，而不是单个组件，尽管它们显然是 专为该意图而设计的产品。它使组织能够简单而又安全地公开和管理 Web API。它将一种更健全、更安全的网关与和合作伙伴管理相关的功能相结合。

图 8 显示了实现 API 管理所需的主要组件，以及所涉及的典型角色。

图 8. API 管理的一个典型模型的示例API 管理的一个典型模型的示例

所有这些角色都在 SOA 中以一种或另一种形式松散地呈现，但它们的实现通常不那么正式。Web API 面向公众的事实已迫使它们变得成熟。典型的角色集合为：

API 产品经理：此角色建立适合销售的 Web API，准备和管理其使用 “计划”，以及使用历史分析评估 Web API 的成功。

API 开发人员：此角色通过配置与提供实际数据和功能的后端系统的连接性和数据映射，提供 Web API 表面背后的实质。

应用程序开发人员：此角色通过 “API 门户” 在产品上利用 Web API，签署协议以通过 API 产品经理定义的一个计划使用它们。

运营：此角色每天监视和管理 Web API，确保它们满足该计划所定义的服务水平。

API 表面背后的架构 “实质” 是什么？

Web API 网关只是 Web API 的表面或暴露点。它没有提供 Web API 所提供的任何实际功能或数据。这让我们能够了解集成架构在企业内演化的全过程 - 从孤立的应用程序成长为点对点通信和中心辐射型中间件，进而潜在地实现 SOA。

诚然，在决定 Web API 的底层实现应来自何处时，高度依赖于企业的演变方式。图 9 显示了最常见的选项的例子：

1.重新公开一个现有的企业服务

2.公开一种通过集线器调节的新集成

3.公开一个已由提供商系统提供的接口

图 9. Web API 实现的选项示例Web API 实现的选项示例

人们很容易认为重新公开现有服务（图 9 中的选项 A）是最常见的。毕竟，SOA 已存在 10 多年，肯定大部分公司都已拥有一套服务。公开这些服务将是从以前对集成的投资中获利的最高效方式。尽管肯定有一些组织在这么做，但由于以下原因，这可能没有您预料的那么常见：

集成成熟度：前面已经提到过，服务通常仅在业务中它们具有价值的特定部分中公开。对于业务的其他部分，其他集成模式（比如中心辐射型或者甚至点对点模式）可能仍然够用。

粒度：因为企业服务通常是根据已知的业务需求而创建的，所以它们通常具有很粗的粒度，带来一个相对较大的数据图，而且可能包含许多子对象。这些操作对移动设备上需要的响应迅速的应用程序而言负担太重，尤其是考虑到设备常常变化的带宽。

安全性：企业服务执行更新操作时，该操作常常以一种特定于企业的方式执行；例如，假设呼叫方的可信度，信道的安全性，或仅供内部使用的安全令牌机制。

相关性：在公司内值得关注的或可销售的数据和功能，通常是无关的或不适合外部公开。我们在 Web API 中寻找的通常是一种全新的市场机会；一个可能公开完全不同的数据的新概念。

因此，图 9 中的选项 B 可能很常见，而且 Web API 使用集成来实现。或许他们在集成集线器本身内重用组件和适配器，但未重用现有服务。

选项 C 目前很少见，因为想要的 Web API 几乎肯定不同于现有应用程序。Web API 网关通常拥有有限的数据转换功能。但是，一旦集成逻辑远远超越基本的数据映射和简单聚合，Web API 网关在架构上就不再适合此逻辑。

基于云的 API 管理

在当今时代，人们渴望减少内部基础设施占地空间，企业在寻找更容易从基于云的提供商获得的功能。API 管理是一个不错的例子。Web API 网关和 API 管理功能都拥有明确的责任，所以它们很容易与内部架构分开，如图 10 所示。因为目标是向外部相关方公开它们，所以托管来自基于云的提供商的 Web API 具有一定的合理性。

图 10. 基于云的 API 管理服务提供商基于云的 API 管理服务提供商

尽管与具体企业相关，但这种基于云的 API 管理特别适合 “诞生于网络” 的公司。举例而言，一家创业公司选择不建立内部基础设施，将所有功能托管在基于云的环境中。基于云的 API 管理使他们能够提供单个统一的公开点来供用户查找他们的 Web API，无论这些 API 托管在云中的何处。

使用此方法，您需要考虑以下因素：

访问控制：您如何向基于云的 API 管理服务安全地提供访问您的内部中间件或实际操作系统的能力？显然，需要某种形式的安全连接器，但您准备交给外部相关方多大的控制权？

延迟：Web API 的用户现在需要在互联网上进行两次跳跃，才能到达您的站点：第一次跳跃到 Web API 提供商，然后再跳跃到您的组织。Web API 似乎更加 “口语化”，这意味着您通常需要执行更多调用来达到相同的目的。因此，更多的最终用户在等待与通信延迟相关的时间。依赖于服务的全球覆盖范围和 Web API 交互通常的繁忙程度，这种额外的延迟可能很高。API 管理解决方案常常提供了缓存选项来为适合该模式的请求减少此延迟。

企业内的 API - SOA 中的下一个阶段？

新的 “REST” 风格的 JSON/HTTP 接口更加轻量型，适合且受现代编程语言和框架支持。API 管理网关产品越来越成熟。为什么还要在企业内利用所有这些优点？许多人现在将内部 API 管理层视为一种替代方案，而且在一些情况下，是一种在企业内公开数据和功能的更有效方式 - 图 4 中所示的服务公开网关的扩展。

图 11 显示了实现内部和外部 API 的单一管理点所需的最低限度的架构配置。这带来的附加优势是，内部用户可直接使用外部公开的 API，而无需路由到互联网。事实上，企业常常仍然更喜欢拥有单独的内部和外部 API 网关，以实现更可靠的关注分离。

图 11. 针对内部和外部用户的 API针对内部和外部用户的 API

所以对一些人而言，API 已成为其公司内朝面向服务的架构发展的旅程中的下一个阶段，以及它们实现外部公开的机会。

一种新的 B2B 形式

另一个值得考虑的案例是，不断成熟的 Web API 技术和实践被用于提供业务间 (B2B) 通信。B2B 接口从任何角度讲都不再新颖。几十年来，企业已使用了各种标准来交换数据，比如与电子数据交换 (EDI) 相关的标准。由于针对特定行业需求的专门化，用于实现它们的标准和工具必然非常深入和复杂。许多企业需要一种更加轻量型的备用方案来交换数据，但它们仍然需要满足一些核心需求，比如安全功能和合作伙伴自助管理。即使公司未计划向一般大众提供 API，对 API 管理的安全性和合作伙伴管理方面的利用可能对实现与特定业务合作伙伴的简单的私有接口很有价值。

超越 Web API

尝试猜测由于最近几年此领域的技术进步，集成架构会如何发展，会很困难且可能很愚蠢。但是，这似乎涉及到进一步认识移动用户近期的现状。一个重要因素是，对于更庞大的社区，人们对 “始终在线” 的渴望仍转变为 “间歇性连接”。

这意味着基于消息的事件驱动的交互的复兴。我们已看到更多基于事件订阅的交互模型。例如，所有主要移动供应商都拥有向设备推送事件的机制。传感器现在能够在得到更广泛认可的协议中发出事件，比如传感器与事件订阅者之间不那么专门的耦合。“物联网” 正在一切事物中都引入传感器，从可穿戴技术到互联汽车，再到一种不同类型的应用程序。这些可能不太关注从操作系统中获取的特定数据，而更重视密切注意所关注的主题，智能地解释所收到的事件。

结束语

回头看看 图 1，您可以看到集成架构如何实现向更多的公众渐进地公开业务功能，还可看到用于实现这一公开的功能的不断成熟。API 管理是这一领域的最新技术，认识到不断开发的模式、技术和概念（比如中心辐射型架构和 SOA）在正确的情况下仍有用且合适，这很重要。