REST和SOA应用的关键区别

软件架构师一直在争相利用多连接组件去创建可分解的应用。这一模式的开发经济性更好，应用生命周期管理(ALM)也更容易，但却会引起软件模型组件化的问题。

应用应该给予轻量Web模式的表述性状态转移(REST)，还是该基于经受住商业考验的面向服务架构(SOA)?答案取决于开发从哪里开始，组件的属性如何，以及应用与瘦客户应用的联系紧密到何种程度。

REST和SOA应用的关键区别

REST和SOA应用最大的区别也许在于控制状态(即在工人事务或请求的整体流程中给定消息的上下文)的机制。需要支持这两类状态控制策略的软件设计是很不一样的。架构师首先要问的问题是软件是否默认已经做出REST或SOA的选择。在SOA中，状态控制往往驻留在每一个组件上。组件之间的关系必须通过逻辑流程维护以便消息个体不在上下文以外进行解释。而REST中状态则是作为消息的一部分从一个组件传给另一个组件。

REST和SOA应用的第二大区别是后者在描述组件间接口、基于接口的绑定，以及功能性方面往往有着更强大的工具。尽管通过RESTful流程管理组件绑定还是有可能的，甚至还可以进行浏览和动态绑定，但是这些工具限制更多，远未标准化。这意味着对于高度动态的组件工作流来说，SOA也许会更好。

基于遗留设计的应用适配

最近的2010年，公司报告说自己大部分的业务应用是从至少5年前的设计和代码演变而来的。这些软件实践在执行上是模块化的，但尚未组件化，因此并未对组件化和工作流控制之类的问题给予特别的考虑。甚至在一些后来做了组件化和工作流的地方，公司报告说基本的应用逻辑大体上仍原封不动。

只要应用基本上是基于遗留设计的，几乎就可以确定该应用是用有状态组件编写。这意味着想让应用与REST适配会困难很多。反之，SOA很容易就可以适应有状态组件。

在不需要大规模重做的情况下，可以用遗留应用来搭建有状态Web服务。如果某个应用相对成熟，则可假定应采用SOA进行组件化，除非存在明显的应用重设计需求。

如果你正在开发新应用或新组件，那么遗留设计对你选REST还是SOA的负担就没那么重了。此处的问题可能是组件间交互的性质如何。有两点要看一下：水平伸缩或云爆发的需求，以及多阶段提交或可靠事务处理的需求。

实现REST和SOA应用的混合设计

既然组件间的RESTful接口在消息中携带了必要的状态信息，很容易就复制多份组件以适应工作负载的变化，或者在工作量变少时减少拷贝数。在SOA中，此类伸缩会更加复杂，因为新的组件不一定能正确继承流程状态，并因此在错误的上下文中处理消息。一般而言，应用越类似Web或云化，用RESTful接口来开发的可能性就越高。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友