集成架构：面向服务与Web API集成
|
与之前出现的越来越复杂的 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 的方式发生大量的修正。在本教程中，我们主要关注架构的区别。在架构上，您显然仍然需要某种形式的公开网关，但对该网关的需求拥有一些新元素。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
