SOA与API的分裂和统一-InfoQ

虽然 API 和 SOA 有着相似的商业和技术目标，许多 API 的支持者却坚持表示 API 与 SOA 几乎没什么关联，认为它们属于截然不同的方法。他们经常宣扬务实的 REST API 和 SOA 之间有着巨大的差异。分工限制了 SOA 服务和 RESTful API 无法干净利索地集成到一个统一的架构中。

团队必须在 SOA 和 API 的观点之间建起一座桥梁，构建一个实际的规划去融合 API 和 SOA。

“做 REST”和“创建 API”的团队通常的关注点是，以增量的外部扩展、具体的演示和不涉及复杂技术的核心业务用例来克服技术和业务的障碍。而 SOA 团队通常关注的是，获得扩展效率、达到商业标准、建立决策中心和满足复杂的非功能性需求。

通过结合 API 和 SOA 的观点，当遵循商业策略和扩展需求时团队就能够迅速地交付业务解决方案了。

务实的 REST API 关注点

REST 是一种系统开发的架构风格，它强制实行一系列服务交互的约束。正规的 REST 约束包括客户端 - 服务端和无状态的交互、可缓存的响应、不变的契约、分层的系统设计和按需编码。这些约束有利于特性的显现，也就是简单性、可扩展性、可变性、可靠性、可见性、性能和可移植性。满足 REST 约束的系统称为 RESTful。RESTful 设计方法能够增加许多的收益：

使数据和服务更易于访问
降低入门门槛
尽最大可能扩展受众数量
使 API 或服务被大量的用户代理消费
使数据和服务逐步演进
在运行期扩展系统
对资源的修改不会影响到客户
动态指导客户行为
使系统可扩展、可靠和高性能
简单
可缓存
原子性

虽然 RESTful 设计有益于支撑 SOA 的目标，但务实的 REST 的战略关注点与许多 SOA 的举措不同。务实的 REST API 设计团队专注于自下而上的应用场景、友好的协议或格式（比如 HTTP、JSON、DNS）、宽容的接口定义和简单的交互模型（比如在保证送达之上的重试）。

务实的 SOA 关注点

务实的 SOA 专注于面向服务的模式，该模式着重于增加软件资产的价值。基本的面向服务的模式是：

共享和重用资产
将冗余的功能固定到稳定的部件中
使项目遵守公共标准和最佳实践

应用这三种模式将减少 IT 环境的复杂度，带来更大的灵活性，比如，能够更加快速地构建应用、更加快速地修改以处理需求的变更。面向服务的模式推动开发团队去评估软件资产满足商业干系人需求的能力。

务实的 SOA 最佳实践

务实的 SOA 团队不强行推进公共（而且复杂）的标准。务实的 SOA 团队提供有价值的商业能力、降低应用的阻力并交付独特的服务价值。

务实的 SOA 团队不鼓吹难以操作的最佳实践。他们依靠团队间的传帮带和自动化的治理以简化最佳实践的应用，这使团队可以更轻松地做正确的事情。

务实的 SOA 团队会留意技能差异和应用的障碍。他们提供加速器包（比如架构、工具、框架和 API 或服务构建块）减少培训、增加自助服务的应用，以及加快项目的交付速度。

务实的 SOA 团队会平衡企业治理与项目的自主权。而不是竖立开发和注册门槛，成功的团队引入若干机制去改进服务、间接的交互、硬性服务水平并促进自助服务的应用，通过引入这些机制使团队促进服务的开发、服务的共享和服务的应用。你可以把这些机制当成现有 API 管理的核心。

务实的调和

REST 与 SOA 是不同的，虽然它们并非格格不入。服务可以成为 RESTful，RESTful 资源也可以成为服务。像 SOA 一样，REST 是由一组设计原则定义的架构规程，REST 还强制施行一组架构约束。REST 使用以资源为中心的模型，这与以对象为中心的模型截然相反（比如，通过资源来封装行为）。在 REST 中，你感兴趣的每件事物都是资源。当进行 RESTful 服务（也叫作 API）的建模时，以一组资源来封装和暴露服务的能力。

因为 SOA 所呈现的架构目标状态通常与目前遗留的 IT 资产是有一定差异的，所以 SOA 是一个漫长的架构之旅，而不是一种短期实现。因为 API 使组织内外的业务能力相互连通，所以 API 能够为商业干系人提供一个平台，使他们可以在其上发起企业 IT 革新以及实行务实的业务。

什么时候去创建服务或者去创建 API

当正要创建一个同时包含 SOA 和 REST 的统一架构策略时，下一个合乎逻辑的问题是：什么时候去创建服务或者去创建 API 呢？从消息传递的观点来看，服务和 API 有相似的属性。它们都是可访问的的网络终端，通过访问交付数据或触发事务。从架构的观点来看，服务和 API 都提供了分离关注点、创建松耦合解决方案的机会。许多架构师和开发人员都想要随着 API 一起扩展他们面向服务的架构（SOA），但并不清楚什么时候去创建服务或者去创建 API。

什么时候创建服务？

作为一个可访问的网络终端，一项服务是一项已经发布的业务或者数据。当团队要跨网络域或运行期应用共享业务能力或业务数据时，创建服务。

服务应当实现一个适当自动化的业务任务，不应该设计成与其他组件交互的精细化组件。当服务暴露了业务流程中的一项独立任务时，开发人员和业务分析师更喜欢去获悉服务的目标。以业务任务的粒度去设计服务，减少服务的交互复杂度，简化应用的维护工作。举一些适合于面向服务的方法的业务任务的示例，它们包括“提交订单”、“检索客户记录”以及“缴费”。

接口与实现分离

服务封装了特定的实现，服务终端通常在服务与后端业务逻辑之间有一个一对一的关联关系。服务应该通过多种接口风格（比如面向资源的、发布 / 订阅的、方法调用的）暴露业务能力或数据。为了最大化有效性和范围，服务实现应该通过多种消息协议（比如 HTTP、JMS、MQ）和消息格式（比如 JSON、XML、CSV）去发布可访问的接口。

RESTful是一种接口风格。这种网络非常适用于移动应用、瘦 JavaScript 客户端应用以及跨网络和所有域的 bash 脚本访问函数。

理想情况下，接口风格不仅是详细的解决方案，还是重要的管理特性（比如安全性、服务层的强制实施、用法跟踪等），在所有接口风格（比如面向资源的、发布 / 订阅的、方法调用的）中这些特性都是有效的。图 1 展示了外观模式，连接了一个单一的服务实现和多个消费者：

图 1：API 外观模式

内在表征与外部契约和外部协议的分离，肯定会影响随着时间去演变服务实现的能力。当从已有的实现中清晰地分离出接口时，开发人员就可以修改其实现而不会影响到使用该服务的应用调用了。

然而，从共享的应用平台消除消费者和提供者的耦合，以及从实现中消除接口耦合都会增加额外的关注点。例如，如果试图使操作语义（比如身份、服务层、授权）跨不同的平台和分布式环境无缝地流转，那么难度就增大了。团队依靠中间件基础设施去桥接跨所有参与者和组件的语义。

因为从实现中分离接口引入了复杂度和额外的工作量，许多团队把接口紧紧地绑定在实现上。通过下述的架构最佳实践，并引入 API 外观或代理终端（使用自动化开发），团队可以增强解决方案的可维护性和适应性。

什么时候创建 RESTful API？

RESTful API 是一种与服务实现互补的接口风格。可在以下时机创建 RESTful API，当要共享控制领域（比如业务单元、组织）之外的服务时，当以扩大影响范围和消费群体为目标时，当要提供跨本地 web 基础架构的服务时，或者对服务端、接口和实现的不对称演进极其感兴趣时。

如果开发团队发布已有服务前的 API 外观，他们要从服务的实现中分离出服务的接口。API 端点是实施安全、监控使用和流量整形的轻量级代理。代理使消费者接口合约和后端服务的实现可以清晰地分离。

当应用服务器、企业服务总线节点或者数据服务主机可以发布 API 端点的时候，API 网关是由 API 传送机制优先管理的。托管的 API 是：

可主动发布和订阅
与相关已经发布的服务级协议（SLA）一起有效
安全的、已认证的、已授权的且受保护的
通过分析可监控和可货币化

服务接口或 RESTful API 接口

RESTful API 与服务是不一样的，虽然它们并非格格不入。服务可以成为 RESTful，RESTful 资源也可以成为服务。像 SOA 一样，REST 是由一组设计原则定义的架构规程，REST 还强制施行一组架构约束。

RESTful API 接口是服务接口中一个有约束的子集。RESTful API 暴露面向资源的接口，理想情况下符合 HATEOS（超媒体作为应用程序状态引擎）。RESTful API 发布资源为中心的模型，它与对象为中心的模型相反（比如，行为是以资源来包装的）。在 REST 中，感兴趣的每样“事物”都是一个资源。当对一个 RESTful 服务（也叫做 API）建模时，服务的能力作为一组资源进行包装和暴露。

去创建一个 RESTful API：

为所有事物指定“ID”
将所有事物链接在一起
使用标准 HTTP 方法
允许多种消息格式的表述
减少共享的状态

新兴的 API 设计工具将帮助你把一个服务实现转换成一个 RESTful API。

关于作者

Chris Haddad 在WSO2 领导平台传道。他居住在 Space Coast Florida，他在那儿观看火箭发射，做冲浪运动，以及编写架构最佳实践。针对云、DevOps 和以API 为中心架构的应用，Chris 汇集了很多以IT 业务为目标的通信战略和战术经验，这些经验都来自于他的亲自实践，极具实用价值。