每当一些 Web 应用服务提供方提出允许开发者集成他们的服务的 Web 服务 API 时，大家都非常关心由 API 实现的互操作设计模式。如果 API 使用的是 REST 样式的互操作，REST 方法的拥护者就会将该 API 作为说明为什么 REST 样式服务比 SOAP 样式服务更优越的重要例子而加以称赞；同样地，如果 API 使用 SOAP 样式 Web 服务模式，情况也类似。似乎很少有人关心这样的一个事实，模式的选择主要取决于正在被执行的应用程序的类型，并且像所有优秀的体系结构决策一样，开发者应该将他们的选择基于正在被开发的应用程序的特定技术需求和特性，而不是基于针对单一体系结构方法的一些特殊偏好。
从基本原理层次上说，REST 样式和 SOAP 样式 Web 服务的区别取决于应用程序是面向 资源的还是面向 活动的。
面向资源服务集中于明确的数据对象，一些基本、标准的操作可以依据这些数据对象而执行。如权威的 Gang of Four（GoF） 设计模式这本书所述，对于熟悉面向对象设计模式概念的开发者来说，面向资源服务与基本 Memento 模式类似。实际上，服务提供方维护一组资源，并且公开一组基本操作来执行以下任务：
- 检索资源
- 修改资源
- 创建新资源
- 删除资源
根据定义，REST 样式 Web 服务是面向资源的服务。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作包括：
- GET - 该操作返回已标识资源的状态表示。您可以通过大量的上下文要素来确定状态，例如谁正在提交请求、操作的参数（传入的参数如 HTTP 头或者查询字符串参数）和服务提供方维护的当前会话状态。
- POST - 该操作执行对已标识资源的一些特定于应用程序形式的更新。该操作行为完全依赖于实现它的服务。由该操作返回的数据也完全依赖于应用程序。举例来说，像 GET 操作一样，它可以返回一个状态表示，它还可以选择根本不返回任何数据。
- PUT - 该操作在已标识位置（URI）创建新资源。操作输入必须包括一个资源的状态表示。它完全依赖服务来创建基于这个状态表示的资源。
- DELETE - DELETE 操作销毁已标识位置（URI）的资源。
在许多方面，REST 样式 Web 服务与 SQL、元组空间（tuple spaces）、简单消息列队等技术相似。它们都使用普通的简单操作针对明确的资源起作用。
- SQL - SELECT、INSERT、DELETE、UPDATE 等
- 元组空间 - GET、PUT
- 消息列队 - SEND、RECEIVE
在每一个案例中，服务接口的设计允许您移动关于资源的信息，让其依赖于请求方来指出希望通过这些信息来做什么。
与此相对的是 面向活动的资源。该类型的应用程序集中于您可能执行的操作，而不是集中于操作所依靠的资源。活动服务的一个简单的例子就是银行事务，在那里用户可以把钱从一个账户转移到另一个账户上。用户不想直接操作资源（钱、银行账户等等），他们只想告诉银行他们想要达到的目的，并且让银行根据他们的利益对资源进行处理。用 GoF术语来描述应用程序：
- 命令
- 中介方
- 策略
- 代理设计模式
面向资源服务不管资源的类型怎样，执行的操作可以保持相对不变，与面向资源服务不同，面向活动服务的操作完全依赖于正在执行的活动类型。例如，银行服务可以公开一个名为
transferFunds 的操作，该操作不同的输入将完全决定服务的资金转移功能。
在面向资源的服务中，一组普通操作担当支持性的工作角色，为客户端提供访问和操作资源。然而，资源是关注的中心，如下面 图 1 所示。
在面向活动服务中，对客户端请求执行的每个活动的单一操作来说，操作是关注的中心。
SOAP 样式 Web 服务通常是面向活动的。 WSDL 文档定义并描述特定于服务的操作。操作由特定于服务的消息交换组成。每一个操作都是一个可以执行的活动。那些正在被执行的操作所针对的内容通常是不相关的。正如 Web 服务资源框架系列规范所描述的，资源可以隐含在活动之中，但是这种隐含与活动的定义不相关，并且只是为了改进执行活动所依赖的上下文。与针对资源而执行活动的面向资源服务相比，它和用来访问资源的服务接口互不相关。
本文转自 张善友 51CTO博客，原文链接：http://blog.51cto.com/shanyou/74906，如需转载请自行联系原作者