从基本原理层次上说,
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
能实现的所有功能,而且更为简单。
分享到:
相关推荐
· 理解基于SOAP的和REST样式的服务的区别 · 编写、部署和使用基于SOAP的核心Java服务 · 理解Web服务描述语言(WSDL)服务契约 · 认识SOAP消息的结构 · 学习如何交付基于Java的RESTful Web服务和消耗...
· 理解基于SOAP的和REST样式的服务的区别 · 编写、部署和使用基于SOAP的核心Java服务 · 理解Web服务描述语言(WSDL)服务契约 · 认识SOAP消息的结构 · 学习如何交付基于Java的RESTful Web服务和消耗商业RESTful...
看了网上好多对REST的介绍,非常理论,让人很难耐着性子看完。...每个对象都有自己独特的方法以及仅公开一个URI的RPC样式Web服务,URI表示单个端点。它忽略HTTP的大部分特性且仅支持POST方法。比如上面
16.5.4 Web应用的商业主机服务 16.6 数据库服务器的安全性 16.6.1 用户和权限系统 16.6.2发送数据至服务器 16.6.3 连接服务器 16.6.4 运行服务器 16.7 保护网络 16.7.1 安装防火墙 16.7.2使用隔离区域(DMZ) 16.7.3...
16.5.4 Web应用的商业主机服务 16.6 数据库服务器的安全性 16.6.1 用户和权限系统 16.6.2发送数据至服务器 16.6.3 连接服务器 16.6.4 运行服务器 16.7 保护网络 16.7.1 安装防火墙 16.7.2使用隔离区域(DMZ) 16.7.3...
16.5.4 Web应用的商业主机服务 16.6 数据库服务器的安全性 16.6.1 用户和权限系统 16.6.2发送数据至服务器 16.6.3 连接服务器 16.6.4 运行服务器 16.7 保护网络 16.7.1 安装防火墙 16.7.2使用隔离区域(DMZ) 16.7.3...
所有的请求都是统一通过RESTAPI进行相应的资源与服务的请求,这样就能够保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性,同时也能够根据业务进行相应统一且透明的内存缓存 ...
书中沿袭深受读者欢迎的step by step风格,通过丰富的练习引导读者逐步构建windows应用程序,访问sql server数据库,开发asp.net web应用程序,创建并使用web服务等。 全书共29章,结构清晰,叙述清楚。所有练习均...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...
多协议扩展支持(REST, RPC, SOAP, etc) Rails3消息队列系统 Sidekiq Sidekiq 为 Rails 3 应用程序提供一个高效的消息队列系统。 Java文件上传组件 COS FAT文件系统读写类库 fat32-lib fat32-lib 是一个用来读写...