REST与SOAP样式Web 服务的区别

    转者注:明天考SOC(Service Oriented Computing),其中概念比较多。和同学交流了SOAP协议和REST框架的区别,结合课件,查询资料,觉得这篇文字解释的简单合理,就转了。按照自己的理解,本质上来说,REST不是一种协议,它是建立在HTTP上的一种框架,面向资源;而SOAP是一种建立在XML基础上的协议,其面向活动,较REST比较复杂,是先前比较占主导地位的web service协议。好了,大家看看下文吧:


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

你可能感兴趣的:(面向服务的计算)