摘要: 简单对象访问协议(Simple Object Access Protocol,SOAP)是一种基于 XML 的协议,可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP),简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME),基于“通用”传输协议是 SOAP的一个优点。
简单对象访问协议(Simple Object Access Protocol,SOAP)是一种基于 XML 的协议,可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP),简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME),基于“通用”传输协议是 SOAP的一个优点。它还支持从消息系统到远程过程调用(Remote Procedure Call,RPC)等大量的应用程序。SOAP提供了一系列的标准,如WSRM(WS-Reliable Messaging)形式化契约确保可靠性与安全性,确保异步处理与调用;WS-Security、WS-Transactions和WS-Coordination等标准提供了上下文信息与对话状态管理。
相对而言,SOAP协议属于复杂的、重量级的协议,当前随着Web2.0的兴起,表述性状态转移(Representational State Transfer,REST)逐步成为一个流行的架构风格。REST是一种轻量级的Web Service架构风格,其实现和操作比SOAP和XML-RPC更为简洁,可以完全通过HTTP协议实现,还可以利用缓存Cache来提高响应速度,性能、效率和易用性上都优于SOAP协议。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法,这种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。REST架构尤其适用于完全无状态的CRUD(Create、Read、Update、Delete,创建、读取、更新、删除)操作。
基于REST的软件体系结构风格(Software Architecture Style)称之为面向资源体系架构(Resource-oriented Architecture,ROA)。按照REST原则设计的软件、体系结构,通常被称为“REST式的”(RESTful),在本文中以下称之为RESTful Web服务,以便于和基于SOAP的Web服务区别。
服务器端采用J2EE,客户端采用JSP、Flex、JavaFX、AIR等可以直接调用Servlet,其他的实现技术基本上不能直接调用,但是无论是那种客户端,对于基于SOAP的Web服务或者基于RESTful Web服务务都是支持的,如AJAX的 XMLHttpRequest、Flex的HTTPService等。
HTTP 的 GET、HEAD 请求本质上应该是安全的调用,即:GET、HEAD 调用不会有任何的副作用,不会造成服务器端状态的改变。对于服务器来说,客户端对某一 URI 做 n 次的 GET、HAED 调用,其状态与没有做调用是一样的,不会发生任何的改变。 HTTP 的 PUT、DELTE 调用,具有幂指相等特性 , 即:客户端对某一 URI 做 n 次的 PUT、DELTE 调用,其效果与做一次的调用是一样的。HTTP 的 GET、HEAD 方法也具有幂指相等特性。 HTTP 这些标准方法在原则上保证你的分布式系统具有这些特性,以帮助构建更加健壮的分布式系统。 安全控制 为了说明问题,基于上面的在线用户管理系统,我们给定以下场景: 参考一开始我们给出的用例图,对于客户端 Client2,我们只希望它能以只读的方式访问 User 和 User List 资源,而 Client1 具有访问所有资源的所有权限。 如何做这样的安全控制? 通行的做法是:所有从客户端 Client2 发出的 HTTP 请求都经过代理服务器 (Proxy Server)。代理服务器制定安全策略:所有经过该代理的访问 User 和 User List 资源的请求只具有读取权限,即:允许 GET/HEAD 操作,而像具有写权限的 PUT/DELTE 是不被允许的。 如果对于 REST,我们看看这样的安全策略是如何部署的。如下图所示: 图 4. REST 与代理服务器 (Proxy Servers)
![REST](http://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/images/4.jpg)
![REST](http://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/images/5.jpg)
![REST](http://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/images/6.jpg)
![REST](http://www.ibm.com/developerworks/cn/webservices/0907_rest_soap/images/7.jpg)
【接口开发】浅谈 SOAP Webserver 与 Restful Webserver 区别
接口,强大,简单,交互,跨越平台
下面简单阐述这两大接口思想
一 REST:
REST是一种架构风格,其核心是面向资源,REST专门针对网络应用设计和开发方式,以降低开发的复杂性,提高系统的可伸缩性。
REST提出设计概念和准则为:
1.网络上的所有事物都可以被抽象为资源(resource)
2.每一个资源都有唯一的资源标识(resource identifier),对资源的操作不会改变这些标识
3.所有的操作都是无状态的
REST简化开发,其架构遵循CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建,获取,更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符(Universal Resource Identifier,URI)来识别和定位资源,并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。
由于REST强制所有的操作都必须是stateless的,这就没有上下文的约束,如果做分布式,集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。
二 SOAP
SOAP偏向于面向活动,有严格的规范和标准,包括安全,事务等各个方面的内容。
SOAP强调操作方法和操作对象的分离,有WSDL文件规范和XSD文件分别对其定义。
而REST强调面向资源,只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。
如何确定使用REST:
若本身只是简单的CRUD业务操作,那么抽象资源就比较容易。
而对于复杂的业务活动抽象资源并不是一个简单的事情,比如校验用户等级,转账,事务处理等。
如何确定使用SOAP:
若有严格的规范和标准定义要求,且前期需要指导多个业务系统集成和开发的时,
因SOAP风格有清晰的规范标准定义,SOAP更适合。
我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。
一句话:
简单数据操作,无事务处理,开发和调用简单使用REST架构风格较好。
再者:
REST核心是url和面向资源,url代替了原来复杂的操作方法。
REST允许我们通过url设计系统,就像测试驱动开发使用测试用例设计类接口一样。
所有可以被抽象为资源的东西都可以使用RESTful的url。
REST关键:
使用REST的关键是如何抽象资源,抽象的越精确,对REST的应用越好。
———————————————————————————————————————
三 REST思想
1.面向资源的接口设计
所有的接口设计都是针对资源来设计的(包括操作也是一种资源)。
URI的设计也是体现了对于资源的定位设计。
2.抽象操作为基础的CRUD
Http中的get,put,post,delete分别对应了read,update,create,delete四种操作
如果仅仅是作为对于资源的操作,抽象成为这四种已经足够了,但是对于复杂的业务接口,未必能够满足。
完全按照REST的思想来设计,那么适用的环境将会有限制,而非放之四海皆准的。
3.Http是应用协议而非传输协议
部分认为:REST的理念设计,其实是作了一套私有的SOAP协议,因此称之为REST风格的自定义SOAP协议。
4.无状态,自包含
接口设计都需做到这点,不仅仅是REST,也是作为可扩展和高效性的最基本的保证,SOAP也类似。
四 SOAP Webservice和RESTful Webservice的比较
1.成熟度(总的来说SOAP在成熟度上优于REST)
SOAP对于异构环境服务发布和调用,以及厂商的支持都已经达到了较为成熟的情况。
REST国外很多大网站都发布了自己的开发API,很多都提供了SOAP和REST两种Web Service,
但是由于REST只是一种基于Http协议实现资源操作的思想,因此各个网站的REST实现都自有一套。
REST实现的各种协议仅仅只能算是私有协议,当然需要遵循REST的思想。
2.效率和易用性(REST更胜一筹)
SOAP协议对于消息体和消息头都有定义,同时消息头的可扩展性为各种互联网的标准提供了扩展的基础,
WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP
处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视,其实很大一方面也是因为其高效以及简洁易用的特性。
这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计,
同时也最大限度的利用了Http最初的应用协议设计理念。
同时,REST很好的融合当前Web2.0的很多前端技术来提高开发效率。
例如:很多大型网站开放的REST风格的API都会有多种返回形式(XML,JSON,RSS,ATOM)等形式。
3.安全性
SOAP在安全方面使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的,
当前已经得到了各个厂商的支持,.net ,php ,java 都已经对其有了很好的支持。
REST 开放REST风格API的网站主要分成两种:
一种是自定义了安全信息封装在消息中,
另外一种就是靠硬件SSL来保障,这只能够保证点到点的安全,如果是需要多点传输的话SSL就无能为力了。
安全这块其实也是一个很大的问题。
五 应用设计与改造
我们的系统要么就是已经有了那些需要被发布出去的服务,要么就是刚刚设计好的服务,但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些,而对于一些复杂的服务接口来说,可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道,很多网站还要传入function的名称作为参数,这就明显已经违背了REST本身的设计思路。而SOAP本身就是面向RPC来设计的,开发人员十分容易接受,所以不存在什么适应的过程。总的来说,其实还是一个老观念,适合的才是最好的
技术没有好坏,只有是不是合适,一种好的技术和思想被误用了,那么就会得到反效果。REST和SOAP各自都有自己的优点,同时如果在一些场景下如果去改造REST,其实就会走向SOAP(例如安全)。
REST对于资源型服务接口来说很合适,同时特别适合对于效率要求很高,但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义,关键还是看应用场景。
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口,其实都是在学其形,不知其心,最后弄得不伦不类,性能上不去,安全又保证不了,徒有一个看似象摸象样的皮囊。
(本文结合各大博客论坛,学习,借鉴,总结而来,欢迎转载)