整合

什么是 API?

应用编程接口 (API) 由一组工具、定义和协议组合而成,可用于构建应用软件。它能让您的产品或服务与其他产品和服务进行通信,而且您不必知晓后者的实施方式。API 可以简化应用的开发,从而为开发人员节约时间并为公司节约资金。在您开发新的工具和产品或管理现有的工具和产品时,API 可以帮助您实现灵活性,简化设计、管理和使用,并提供创新机遇。

例如,假设有这样一家图书发行公司:该图书发行商可以为其客户提供一个应用,以供书店店员查看该发行商的图书供应情况。这款应用的开发成本高昂、存在平台限制、开发周期较长,还需进行日常维护。

或者,该图书发行商也可以提供一个 API,以用于查看库存情况。这一方案有以下几个好处:

  • 让客户通过 API 访问数据可以帮助他们将所有库存相关信息汇集到一处。
  • 只要 API 的行为不发生变化,该图书发行商就能在不影响客户的情况下更改内部系统。
  • 借助公开可用的 API,为该图书发行商、图书销售商或第三方服务的开发人员可以开发一个应用,以帮助客户查找所需的图书。这样不仅能提高销量,还能带来其他的商机。

简而言之,API 既能让您开放自己的资源访问权限,又能确保安全性并让您继续握有控制权。如何以及向谁开放访问权限则由您来决定。借助整合各种资源(包括传统系统和物联网(IoT))的分布式整合平台,可以连接至 API 并创建使用 API 所提供的数据或功能的应用。

关于 API 的发布策略,共有三种方案可供选择。

私有

这类 API 仅供内部使用,能让公司最大限度地控制自己的 API。

合作伙伴

您会和特定的业务合作伙伴共享这类 API。它能在不影响质量的情况下提供额外的收入流。

公共

这类 API 可供所有人使用。第三方可以使用这类 API 来开发应用,以便与您的 API 进行互动或实现某种创新。

利用 API 实现创新

通过向合作伙伴或公众提供您的 API,可以:

  • 创造新的收入渠道,或拓展现有收入渠道。
  • 扩大您的品牌覆盖范围。
  • 通过外部开发和协作,推动开放创新或提高效率。

听上去还不错,对吗?但是,API 是如何做到上述几点的呢?

我们继续以刚才的那个图书发行公司为例。

假设该公司的某个合作伙伴开发了一个应用,可以帮助人们查找书店书架上的图书。这种体验的改进为书店带来了更多的客户(该发行商的客户),并拓展了现有的收入渠道。

或许会有第三方使用某个公共 API 来开发应用,以供人们直接从该发行商处(而非书店)购书。这样就能为该图书发行商打开新的收入渠道。

与特定合作伙伴或全世界共享 API 或许能带来积极的影响。除了自己公司的营销活动之外,每一个合作关系都能帮助您提高品牌辨识度。以公共 API 的形式向所有人开放技术可以激励开发人员以您的 API 为中心构建应用生态系统。有更多的人使用您的技术就意味着可能会有更多的人与您做生意。

公开技术或许能带来意料之外的惊喜。有时,这些惊喜会颠覆整个行业。对于这家图书发行公司而言,新形态的公司(比如图书出借服务)或许能从根本上改变他们的业务开展方式。借助合作伙伴和公共 API,您可以激发社区成员的创意,其人数远超您的内部开发团队。众多的新奇想法会从各方纷至而来,公司需要明辨市场的变化情况并做好相应的准备。API 大有用处。

API 简史

API 出现于计算机时代的早期,在个人电脑诞生之前。当时,API 常被用作操作系统的库,而且基本上都存放在运行它的本地系统上,虽然它有时也会在大型机之间传递消息。近 30 年后,API 走出了它们的本地环境。到了 21 世纪初,API 成为了用于实现数据远程整合的一种重要技术。

远程 API

远程 API 旨在通过通信网络进行互动。这里的“远程”是指 API 操控的资源不在提出请求的计算机上。由于互联网是应用最广泛的通信网络,所以大多数 API 都是基于 Web 标准来设计的。并非所有的远程 API 都是 Web API,但可以认为 Web API 都是远程 API。

Web API 通常会使用 HTTP 来传输请求消息,并提供响应消息的结构定义。这些响应消息通常都会以 XML 或 JSON 文件的形式来提供。XML 和 JSON 都是首选格式,因为它们会以易于其他应用操纵的方式来呈现数据。


API 经过哪些改进?

在 API 逐步发展成为当前随处可见的 Web API 的过程中,人们对它进行了一些改进,以简化它的设计并改进它的实施成效。

少些 SOAP,多些 REST

随着 Web API 的不断普及,相应的协议规范也随之产生了,从而推动了信息交换的标准化:简单对象访问协议,简称 SOAP。使用 SOAP 设计的 API 会使用 XML 格式来收发消息,并通过 HTTP 或 SMTP 来接收请求。使用 SOAP 时,在不同环境中运行的应用或使用不同语言编写的应用能够更加轻松地共享信息。

相关的规范还有一个,即:表述性状态传递 (REST)。遵循 REST 架构约束的 Web API 被称为 RESTful API。REST 从根本上有别于 SOAP :SOAP 是一种协议,而 REST 是一种架构模式。这意味着 RESTful Web API 没有官方标准。正如 Roy Fielding 在论文“Architectural Styles and the Design of Network-based Software Architectures”(架构模式以及基于网络的软件架构的设计)中定义的那样,只要 API 符合 RESTful 系统的 6 个导向性约束,就算作 RESTful API:

  • 客户端/服务器架构:REST 架构由客户端、服务器和资源构成,通过 HTTP 来处理请求。

  • 无状态:请求所经过的服务器上不会存储任何客户端内容。与会话状态相关的信息会存储在客户端上。

  • 可缓存性:通过缓存,可免去客户端与服务器之间的某些交互。

  • 分层系统:客户机与服务器之间的交互可以通过额外的层来进行调解。这些层可以提供额外的功能,如负载均衡、共享缓存或安全防护。

  • 按需代码(可选):服务器可通过传输可执行代码来扩展客户端的功能。

  • 统一接口:这项约束是 RESTful API 的设计核心,共涵盖 4 个层面:

    • 识别请求中的资源:请求中的资源会被识别,并与返回给客户端的表示内容分离开来。

    • 通过不同的表示内容来操纵资源:客户端会收到表示不同资源的文件。这些表示内容必须提供足够的信息,以便执行修改或删除操作。

    • 自描述消息:返回给客户端的每个消息都包含充足的信息,用于指明客户端应该如何处理所收到的信息。

    • 将超媒体作为应用状态的引擎:在访问某个资源后,REST 客户端应该能够通过超链接来发现当前可用的所有其他操作。

虽然看似有很多约束需要遵循,但是这些约束遵循起来要比遵循规定的协议容易得多。因此,RESTful API 现在变得比 SOAP 更为普及。

SOA 与微服务架构

最常使用远程 API 的 2 种架构方案分别是:面向服务的架构 (SOA) 和微服务架构。在这 2 种方案中,SOA 的历史更为久远一些。最初,它是在单体式应用的基础上经过改进而形成的。虽然单个单体式应用也可以完成各种操作,但通过某种整合模式(如企业服务总线 (ESB))在不同应用间实现松散耦合后,即可获得某些功能。

从大多数层面来看,SOA 都要比单体式架构更简单;但是,如果无法明确理解各种组件交互,SOA 也可能会进一步加剧整个环境的复杂性。这种复杂性的加剧会重新引发 SOA 想要解决的某些问题。

对于专用松散耦合服务的使用,微服务架构与 SOA 模式类似。但是,微服务架构会对传统架构进行进一步细分。在微服务架构中,服务会采用通用消息传递框架,如 RESTful API。它们会使用 RESTful API 来实现相互通信,且无需执行繁琐的数据转换处理或使用其他的整合层。使用 RESTful API 可以加速新功能和新更新的交付;甚至还可以说,是这类 API 促进了这种速度的提升。该架构中的每一个服务都呈离散状态。一个服务可以被取代、增强或丢弃,而不会影响架构中的任何其他服务。这种轻量级架构有助于优化分布式资源或云资源,而且能够支持个别服务的动态扩展。

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.