REST与SOA

REST会是SOA的未来吗？

http://www.infoq.com/cn/articles/RESTSOAFuture?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk

SOA的架构风格，是基于企业业务架构的功能性分解，并且引入了两个高层次的抽象：企业业务服务和业务流程。企业业务服务代表的是现有IT能力（和企业的业务功能相一致）。业务流程编排业务服务，并定义业务的整体功能。

REST是一组被称之为面向资源架构（ROA）的架构准则。ROA构建在资源这一概念之上；每个资源都是一个能够直接访问的分布式组件,可通过一个标准的、通用的接口来处理。所以，面向资源的架构（ROA）其最根本的还是一种基于资源的分解。

服务 vs. 资源

何为服务？

在最简单的情况下，服务可以被定义为一个自包含、独立开发、可部署、可管理和可维护的软件实现，它从整体上为企业提供特定的与业务相关的功能，并且在设计上是“可集成的”。“服务”可以通过动词（verb）来定义（例如，“验证客户信用积分”，这描述了服务实现的业务功能）。

服务并不是某个编程结构或一组APIs，而是一个用于实现企业解决方案的架构（设计单元、实现以及维护）和部署构件。服务接口（尤其对某个给定的服务而言）定义服务功能，并且可由多种方式实现。存在两种基本的定义服务接口的方法——RPC风格和消息（messaging）风格。

何为资源？

在最简单的情况下，资源可以被定义为一个可直接访问的、独立开发的、可部署的、可管理的和可维护的软件构件，它支持特定的数据。资源可以通过名词（noun）来定义，比如“医生的预约”就描述了资源提供的数据。某一资源也可以和其他资源相关联并为它们提供引用（链接）。实际上，一个资源就类似于一个对象^[6]，不过它是带有预定义（CRUD）接口语义的对象。

资源通过两部分定义：资源URL和资源所提供的所有操作上定义的输入/输出参数 ^[7]。这和服务不同，服务的方法之间是完全独立，并且能够以独立端点（endpoints）的方式部署，而资源上的方法遵循OO语义，这意味着所有的方法（除 createResource以外）都必须依附于底层的某个资源（同一个URL）。

REST Web服务

REST Web服务方法是指单纯使用REST技术作为通信手段来构建SOA的一种方法。在这种情况下，服务由SOA风格的分解来定义，而基于REST的Web服务^[9]作为通信。

归功于Web的优势和Ajax技术的遍地开花，使用JSON逐渐变成主流的方法；大部分流行的浏览器都内置对JSON支持。由于在JavaScript中处理XML（尤其是带有很多命名空间）并不是一件容易的事，所以，Web实现使用基于JSON的REST Web服务要容易的多。面向Web交互的REST Web服务的扩增导致了这些技术的日益流行和广泛传播。

SOAP和REST最主要的区别在于REST是直接实现于HTTP协议之上，而SOAP引人了一个抽象层（SOAP消息传递），这可以在任何传输协议之上实现。标准化SOAP绑定目前存在于HTTP、SMTP和JMS之上，而非标准化绑定已经在其他一些协议解决方案实现了。这层额外的抽象层（提供协议和基于SOAP实现之间的解耦）是造成SOAP和REST Web服务区别的根源。

。。。。。。。。。。。。。。。。。。。

结论

REST既适用于使用ROA（本真REST方法）的系统设计，也适用于使用REST技术（REST Web服务）的SOA设计实现。虽然两种方法都有其优势，但都没有改变最难的部分——定义和企业业务模型一致的业务服务/资源。有些情况的确两种都适合，但归根到底这完全是两种不同的风格。