SOA与API的分裂和统一
英文原文：SOA and API Schism and Unification
虽然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。
