REST WebService与SOAP WebService的比较

在SOA的基础技术实现方式中WebService占据了很重要的地位,通常我们提到WebService第一想 法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受,同时 各大网站不断开放API提供给开发者,也激起了REST风格WebService的热潮。

SOAP

什么是SOAP,我想不用多说,google一把满眼都是。其实SOAP最早是针对RPC的一种解决方 案,简单对象访问协议,很轻量,同时作为应用协议可以基于多种传输协议来传递消息 (Http,SMTP等)。但是随着SOAP作为WebService的广泛应用,不断地增加附加的内容,使得现 在开发人员觉得SOAP很重,使用门槛很高。在SOAP后续的发展过程中,WS-*一系列协议的制 定,增加了SOAP的成熟度,也给SOAP增加了负担。

REST

REST其实并不是什么协议也不是什么标准,而是将Http协议的设计初衷作了诠释,在Http协 议被广泛利用的今天,越来越多的是将其作为传输协议,而非原先设计者所考虑的应用协 议。SOAP类型的WebService就是最好的例子,SOAP消息完全就是将Http协议作为消息承载,以 至于对于Http协议中的各种参数(例如编码,错误码等)都置之不顾。其实,最轻量级的应用协 议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查,而互联 网上的各种资源就好比数据库中的记录(可能这么比喻不是很好),对于各种资源的操作最后总 是能抽象成为这四种基本操作,在定义了定位资源的规则以后,对于资源的操作通过标准的Http 协议就可以实现,开发者也会受益于这种轻量级的协议。

REST的思想归结以下有如下几个关键点:

1.面向资源的接口设计

所有的接口设计都是针对资源来设计的,也就很类似于我们的面向对象和面向过程的设计区 别,只不过现在将网络上的操作实体都作为资源来看待,同时URI的设计也是体现了对于资源的 定位设计。后面会提到有一些网站的API设计说是REST设计,其实是RPC-REST的混合体,并非 是REST的思想。

2.抽象操作为基础的CRUD

这点很简单,Http中的get,put,post,delete分别对应了read,update,create,delete四种操作,如果仅 仅是作为对于资源的操作,抽象成为这四种已经足够了,但是对于现在的一些复杂的业务服务接 口设计,可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的 问题,如果要完全按照REST的思想来设计,那么适用的环境将会有限制,而非放之四海皆准的。

3.Http是应用协议而非传输协议

这点在后面各大网站的API分析中有很明显的体现,其实有些网站已经走到了SOAP的老路 上,说是REST的理念设计,其实是作了一套私有的SOAP协议,因此称之为REST风格的自定 义SOAP协议。

4.无状态,自包含 这点其实不仅仅是对于REST来说的,作为接口设计都需要能够做到这点,也是作为可扩展和

高效性的最基本的保证,就算是使用SOAP的WebService也是一样。 REST vs SOAP

成熟度:

SOAP虽然发展到现在已经脱离了初衷,但是对于异构环境服务发布和调用,以及厂商的支持 都已经达到了较为成熟的情况。不同平台,开发语言之间通过SOAP来交互的web service都能够较 好的互通(在部分复杂和特殊的参数和返回对象解析上,协议没有作很细致的规定,导致还是需 要作部分修正)

REST国外很多大网站都发布了自己的开发API,很多都提供了SOAP和REST两种Web Service,根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于 Http协议实现资源操作的思想,因此各个网站的REST实现都自有一套,在后面会讲诉各个大网站 的REST API的风格。也正是因为这种各自实现的情况,在性能和可用性上会大大高于SOAP发布 的web service,但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开 发,因此通用性要求不高。

由于没有类似于SOAP的权威性协议作为规范,REST实现的各种协议仅仅只能算是私有协 议,当然需要遵循REST的思想,但是这样细节方面有太多没有约束的地方。REST日后的发展所 走向规范也会直接影响到这部分的设计是否能够有很好的生命力。

总的来说SOAP在成熟度上优于REST。 效率和易用性:

SOAP协议对于消息体和消息头都有定义,同时消息头的可扩展性为各种互联网的标准提供了 扩展的基础,WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增 加。

REST被人们的重视,其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面 源于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了Http 最初的应用协议设计理念。同时,在我看来REST还有一个很吸引开发者的就是能够很好的融合当 前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种 返回形式,除了传统的xml作为数据承载,还有(JSON,RSS,A TOM)等形式,这对很多网站前端 开发人员来说就能够很好的mashup各种资源信息。

因此在效率和易用性上来说,REST更胜一筹。 安全性:

  这点其实可以放入到成熟度中,不过在当前的互联网应用和平台开发设计过程中,安全已经
 被提到了很高的高度,特别是作为外部接口给第三方调用,安全性可能会高过业务逻辑本身。

SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实 现安全控制的,当前已经得到了各个厂商的支持,.net ,php ,java 都已经对其有了很好的支持 (虽然在一些细节上还是有不兼容的问题,但是互通基本上是可以的)。

REST没有任何规范对于安全方面作说明,同时现在开放REST风格API的网站主要分成两种, 一种是自定义了安全信息封装在消息中(其实这和SOAP没有什么区别),另外一种就是靠硬件 SSL来保障,但是这只能够保证点到点的安全,如果是需要多点传输的话SSL就无能为力了。安全 这块其实也是一个很大的问题,今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO,其 实是直接采用了XML-Security和XML-Signature,效率看起来也不是很高。未来REST规范化和通 用化过程中的安全是否也会采用这两种规范,是未知的,但是加入的越多,REST失去它高效性的 优势越多。

应用设计与改造:

我们的系统要么就是已经有了那些需要被发布出去的服务,要么就是刚刚设计好的服务,但 是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设 计上来说按照REST的思想来设计相对来说要容易一些,而对于一些复杂的服务接口来说,可能强 要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道,很多 网站还要传入function的名称作为参数,这就明显已经违背了REST本身的设计思路。

而SOAP本身就是面向RPC来设计的,开发人员十分容易接受,所以不存在什么适应的过程。

总的来说,其实还是一个老观念,适合的才是最好的

技术没有好坏,只有是不是合适,一种好的技术和思想被误用了,那么就会得到反效 果。REST和SOAP各自都有自己的优点,同时如果在一些场景下如果去改造REST,其实就会走 向SOAP(例如安全)。

REST对于资源型服务接口来说很合适,同时特别适合对于效率要求很高,但是对于安全要求 不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求较高的接口设 计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义,关键还是看应用 场景。

同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口,其实都 是在学其形,不知其心,最后弄得不伦不类,性能上不去,安全又保证不了,徒有一个看似象摸 象样的皮囊。

时间: 2024-10-22 06:30:07

REST WebService与SOAP WebService的比较的相关文章

SOAP Webservice和RESTful Webservice

REST是一种架构风格,其核心是面向资源,REST专门针对网络应用设计和开发方式,以降低开发的复杂性,提高系统的可伸缩性.REST提出设计概念和准则为: 1.网络上的所有事物都可以被抽象为资源(resource)2.每一个资源都有唯一的资源标识(resource identifier),对资源的操作不会改变这些标识3.所有的操作都是无状态的 REST简化开发,其架构遵循CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建,获取,更新和删除就可以完成相关的操作和处理.您可以通过

PHP中调用Soap/WebService

关于在PHP中如何调用Soap/WebService的描述,网络上有不少帖子.但是主要讲述了如何用PHP开发服务器端.客户端并加以关联,而很少触及在PHP中调用现成的WebService的情况.在本文中我们做一个简单的示范. 一.寻找WebService来源 WebService可以自己编写,但是也可以从网络上去寻找现成的.我用的是www.xmethods.net里的US Zip Validator.它的WSDL文件位置在:http://www.webservicemart.com/uszip.

Web Service进阶(七)浅谈SOAP Webservice和RESTful Webservice

浅谈SOAP Webservice和RESTful Webservice REST是一种架构风格,其核心是面向资源,REST专门针对网络应用设计和开发方式,以降低开发的复杂性,提高系统的可伸缩性.REST提出设计概念和准则为: 1.网络上的所有事物都可以被抽象为资源(resource) 2.每一个资源都有唯一的资源标识(resource identifier),对资源的操作不会改变这些标识 3.所有的操作都是无状态的 REST简化开发,其架构遵循CRUD原则,该原则告诉我们对于资源(包括网络资源

SOA,Webservice,SOAP,REST,RPC,RMI,JMS的区别与联系(转载)

原文地址:http://blog.csdn.net/pcceo1/article/details/51245249 SOA面向服务的软件架构(Service Oriented Architecture) 是一种计算机软件的设计模式,主要应用于不通应用组件中通过某种协议来互操作 它的基本设计原理是:服务提供了一个简单的接口,抽象了底层的复杂性,然后用户可以访问独立的服务,而不需要去了解服务底层平台实现. 正因为SOA架构实现不依赖于技术,因此能够被各种不同的技术实现. 例如: SOAP, RPC

随便聊聊 SOA & SOAP & WebService 的一些东西,以及客户端开发的代码逻辑解析

http://blog.csdn.net/hikaliv/article/details/6459779 一天的时间调通了一个 WebService 的 Java 端的 C/S.一个 Android 端的 C/S,调通了而已,很不爽,很闷.因为刚刚上手 JAVA & Eclipse,对于我这个用惯了 VS 2010 的同学来说,感觉大大的不好.被迫和陌生的感觉很容易让我这个巨蟹座的男人直接地由然而生强烈的抵触情绪.不过话说回来了,网络方面的东西我一直很感兴趣,苦于没有项目参与.谁让项目要求我 A

webservice通过soap协议出现不能加载wsdl文件解决办法

PHP在用SOAP协议做接口的时候,经常会碰到如下问题,不是不成功,而是偶尔不成功,实在让人费解! ERR: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://www.xxxxx.com/member/member_sync.php?wsdl' : failed to load external entity "http://www.xxxxx.com/member/member_sync.php?wsdl" 查找日志发现: NO

REST & SOAP webservice 小结

REST: REST是一种架构设计,特点是面向资源,存在于互联网的任何事物都可以理解为资源,REST相比较SOAP WS具有比较低的开发门槛. 1. 网络上的事物被抽象成资源,每个资源对应唯一的资源标示(URI) 2. 所有对资源的操作都是无状态的 REST遵循HTTP规范,其对资源的核心操作对应http method - get/post/put/delete(获取.增加.修改.删除),通过URI来获取资源并对其进行操作. SOAP: SOAP有严格的规范和标准,针对安全和事物等的管理更加成熟

webservice、soap、wsdl

搜集了一些关于webservice.soap.wsdl的基本知识,解决工作中遇到的疑问 一 .什么是webservice(用你的话描述webservice)?在什么时候用webservice(webservice能给我们解决什么样的问题)? 一句话概括:WebService是一种跨编程语言和跨操作系统平台的远程调用技术. 所谓跨编程语言和跨操作平台,就是说服务端程序采用Java编写,客户端程序则可以采用其他编程语言编写,反之亦然!跨操作系统平台则是指服务端程序和客户端程序可以在不同的操作系统上运

开发基于CXF的 RESTful WebService web 项目 webservice发布

配置步骤 开发基于CXF的 RESTful WebService 1.创建Web项目并导入CXF的jar 2.在Web.xml中配置 CXFServlet <servlet> <servlet-name>cxf</servlet-name> <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class> </servlet> <servlet-