从基本原理层次上说， REST 样式和
SOAP 样式
Web 服务的区别取决于应用程序是面向资源的还是面向活动的
。 面向资源服务集中于明确的数据对象，一些基本、标准的操作可以依据这些数据对象而执行。如权威的 Gang of Four （ GoF ） 设计模式这本书所述，对于熟悉面向对象设计模式概念的开发者来说，面向资源服务与基本
Memento 模式类似。实际上，服务提供方维护一组资源，并且公开一组基本操作来执行以下任务：
l
检索资源
l
修改资源
l
创建新资源
l
删除资源
根据定义， 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 术语来描述应用程序：
l
命令
l
中介方
l
策略
l
代理设计模式
面向资源服务不管资源的类型怎样，执行的操作可以保持相对不变，与面向资源服务不同，面向活动服务的操作完全依赖于正在执行的活动类型。例如，银行服务可以公开一个名为 TransferFunds 的操作，该操作不同的输入将完全决定服务的资金转移功能。在面向资源的服务中，一组普通操作担当支持性的工作角色，为客户端提供
访问和操作资源。然而，资源是关注的中心，如下面 图 所 示。
面向资源服务与面向活动服务的比较 图
在面向活动服务中，对客户端请求执行的每个活动的单一操作来说，操作是关注的中心。 SOAP 样式
Web 服务通常是面向活动的。
WSDL 文档定义并描述特定于服务的操作。操作由特定于服务的消息交换组成。每一个操作都是一个可以执行的活动。那些正在被执行的操作所针对的内容通常是不相关的。正如
Web 服务资源框架系列规范所描述的，资源可以隐含在活动之中，但是这种隐含与活动的定义不相关，并且只是为了改进执行活动所依赖的上下文。与针对资源而执行活动的面向资源服务相比，它和用来访问资源的服务接口互不相关。
如上所述， REST 是网络软件的构架风格，而 SOAP 是个具体的实现 ( 协议 ) ，两者并不是完全对立的。但基于 SOAP 的 Web 服务广为人知， SOAP 、 WSDL 、 UDDI 等规范几乎成为 Web 服务的代名词。而构建符合 REST 原则的 Web 服务与 SOAP Web 服务有很大不同，有必要把二者区别开来进行研究。
首先， REST Web 服务与 SOAP 使用的寻址模型、接口、对中间媒介和安全性的支持不同。两者交互机制的差异导致 REST 和 SOAP 在对互操作的支持、与 Web 体系结构的关系等方面的区别 。
表 REST 与 SOAP 比较表
|
|
REST
|
SOAP
|
|
寻址模型
|
标准化的 URI 、 DNS;URI 与资源（包括服务）一一对应
|
URI 只用来定位 SOAP 端点；资源与 URI 是一一对应；一端点对应多个资源
|
|
接口
|
提供通用操作，即 HTTP 的 GET 、 PUT 、 POST 和 DELETE
|
不提供通用操作 , 每个服务定义自己的方法（操作）
|
|
中间媒介
|
兼容传统的 Web 中间媒介，包括代理、缓存服务器、网管等
|
不兼容传统的 Web 中间媒介
|
|
安全性
|
简单有效：可用现有防火墙控制
|
十分复杂：不能使用现有防火墙控制
|
1. 耦合度
松散耦合是 Web 服务的声称的一个特点。尽管新的 SOAP 规范中也支持基于消息传递的交互机制，绝大部分 SOAP 实现仍是基于 RPC 调用方式， RPC 方式是紧密耦合的表现 ; 而紧密耦合的系统是无法适应 Web 级的规模可伸缩性的。 REST Web 服务则继承了 Web 松散耦合的特点，客户应用通过逻辑 URL 访问服务，服务的实现对客户来说是完全透明的，客户程序可以对服务的实现技术、方法毫无所知。
2. 对互操作的支持
标准化是互操作的关键。万维网上无数资源间之所以可以互操作，原因在于 WWW 建立在下列标准之上，这些标准也是 REST 的核心组成部分 (rest tutorail ):
l
URI: 用于资源的定位与命名
l
操作资源的通用接口 : 即 HTTP 协议的 GET 、 POST 、 DELETE 和 PUT
l
资源表示 :HTML 、 XML 、 GIF 、 PNG 、 JPEG 等
l
媒体类型 :MIME 类型 ( 如 text/plain 、 text/html 、 image/gif 等 )
基于 SOAP 的 Web 服务则依赖于定制。每个 SOAP 消息使用独特的命名资源的方法，或使用 UUID 、或使用 URN; 每个 SOAP 应用需要定义自己的接口。 SOAP 的这些特点对于服务间的互操作的实现十分不利。
3. 与 Web 体系结构及 Semantic Web 的关系
Web 的体系结构建立在三个概念的基础上，而且这些概念都与资源有关 : 资源的确定、与资源的交互、和资源的表示。这些概念分别与 Web 标准协议相关 :URI 是定位资源的方法， HTTP 协议用于软件代理与资源间的交互， HTML 、 XML 、 PNG 、 PJG 、 RDF 等用于资源的表示。
REST 是对 Web 最成功要素的总结，它建立在一系列标准 Web 协议之上，跟 Web 的关系密不可分。万维网的创始人 Tim Bemers-Lee 提出的 WWW 的远景一语义网络圈 (Semantic Web) ，也建立在 HTTP 、 URI 、 XML 、 RDF 等核心协议之上，这些技术都是这一远景的重要组成部分。基于 SOAP 、 WSDL 、 UDDI 等技术的 Web 服务 (Web Services) 并没有根据 Web 体系结构使用基础的 Web 协议。如 HTTP 一个 Web 应用层协议，在 Web Serivces 技术中被用作可选的传输机制，把 HTTP 本身作为应用协议的特点置之不理，每个 SOAP 应用都需要定义独特的接口 。 URI 是 URL( 统一资源定位符 ) 和 UNR( 统一资源名称 ) 的超集，并能由两者分别或共同表示 ;URL 是最常用的 URI 之一。 URI 是 Web 上资源定位的首要方式， Tim Berners-Lee 甚至认为 URI 是 Web 体系结构的公理，并认为 :1. 不管任何地方的任何资源都可得到一个 URI;2. 任何重要的资源都应该分配一个 URI 。
REST 的观点与此相吻合 : 每个资源都应有一个逻辑 URI 。而在 SOAP 服务中， URI 的角色被定制的寻址方式 ( 如 UUID 、 URN 等 ) 替代 ;URI 只是用来定位 SOAP 服务器，与资源不是一一对应的关系，所有对资源的访问都通过一个 URI 指向的 SOAP 服务器进行 ; 这种做法与语义 Web 的远景也是不相适应的。因此有学者对此颇有批评，认为 SOAP Web 服务不依赖 Web 协议，并不是真正意义上的“ Web ”服务。
经过 REST 团体的努力， SOAP 的支持者也开始认识 REST 的重要性，当前版本 (l.2) 的 SOAP 规范对 REST 提供了部分支持。也就是说，可以使用 REST 的部分原则来构架基于 SOAP 技术的 Web 服务。 IBM 公司的 Sam Ruby 等认为 REST 和 SOAP 的结合产生强大的解决方案，但并没有提出令人信服的证据。和 REST 相比， SOAP Web 服务的唯一优势是得到许多业界厂商的支持。从技术上来说， REST 可以实现 SOAP 能实现的所有功能，而且更为简单。