- 浏览: 138664 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (152)
- 异常以及异常处理框架探析 (1)
- java语法 (18)
- 职场生活 (8)
- js前端 (9)
- Tomcat (8)
- java架构 (23)
- .Net (2)
- Linux (4)
- Spring (6)
- Nginx (7)
- 设计模式 (3)
- JVM (4)
- 数据库 (2)
- 智力题 (1)
- SVN (1)
- Maven (3)
- MYSQL (5)
- java线程池2-任务队列的规则 (1)
- 英语学习 (1)
- 面试题 (7)
- MyBatis (2)
- 并发 (3)
- Memcache (2)
- XML (1)
- Hadoop (1)
- Web容器 (1)
- Struts2 (2)
- 产品运营 (1)
- 安全 (1)
- Mongodb (1)
- Shell (0)
- 恋爱 (1)
- 简单对象访问协议 (1)
- mybatis优化(转) (1)
- 算法 (1)
- Redis (2)
- Spring MVC数据绑定大全 (1)
- 错误搜集 (1)
- IDEA (1)
最新评论
-
sunshine_love:
故事里的事说是就是不是也是 故事里的事说不是就不是是也不是 故 ...
在这个变化的年代,IT人的方向在哪里?看两个故事
RESTful Webservice 和 SOAP Webserivce 对比及区别
接口抽象
RESTful Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象所有 Web 系统的服务能力,而不同的是,SOAP 应用都通过定义自己个性化的接口方法来抽象 Web 服务,这更像我们经常谈到的 RPC。例如本例中的 getUserList 与 getUserByName 方法。
RESTful Web 服务使用标准的 HTTP 方法优势,从大的方面来讲:标准化的 HTTP 操作方法,结合其他的标准化技术,如 URI,HTML,XML 等,将会极大提高系统与系统之间整合的互操作能力。尤其在 Web 应用领域,RESTful Web 服务所表达的这种抽象能力更加贴近 Web 本身的工作方式,也更加自然。
同时,使用标准 HTTP 方法实现的 RRESTful Web 服务也带来了 HTTP 方法本身的一些优势:
无状态性(Stateless)
HTTP 协议从本质上说是一种无状态的协议,客户端发出的 HTTP 请求之间可以相互隔离,不存在相互的状态依赖。基于 HTTP 的 ROA,以非常自然的方式来实现无状态服务请求处理逻辑。对于分布式的应用而言,任意给定的两个服务请求 Request 1 与 Request 2, 由于它们之间并没有相互之间的状态依赖,就不需要对它们进行相互协作处理,其结果是:Request 1 与 Request 2 可以在任何的服务器上执行,这样的应用很容易在服务器端支持负载平衡 (load-balance)。
安全操作与幂指相等特性(Safety /Idempotence)
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)
一般代理服务器的实现根据 (URI, HTTP Method) 两元组来决定 HTTP 请求的安全合法性。
当发现类似于(http://localhost:8182/v1/users/{username},DELETE)这样的请求时,予以拒绝。
对于 SOAP,如果我们想借助于既有的代理服务器进行安全控制,会比较尴尬,如下图:
图 5. SOAP 与代理服务器 (Proxy Servers)
所有的 SOAP 消息经过代理服务器,只能看到(http://localhost:8182/v1/soap/servlet/messagerouter, HTTP POST)这样的信息,如果代理服务器想知道当前的 HTTP 请求具体做的是什么,必须对 SOAP 的消息体解码,这样的话,意味着要求第三方的代理服务器需要理解当前的 SOAP 消息语义,而这种 SOAP 应用与代理服务器之间的紧耦合关系是不合理的。
关于缓存
众所周知,对于基于网络的分布式应用,网络传输是一个影响应用性能的重要因素。如何使用缓存来节省网络传输带来的开销,这是每一个构建分布式网络应用的开发人员必须考虑的问题。
HTTP 协议带条件的 HTTP GET 请求 (Conditional GET) 被设计用来节省客户端与服务器之间网络传输带来的开销,这也给客户端实现 Cache 机制 ( 包括在客户端与服务器之间的任何代理 ) 提供了可能。HTTP 协议通过 HTTP HEADER 域:If-Modified-Since/Last- Modified,If-None-Match/ETag 实现带条件的 GET 请求。
REST 的应用可以充分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后,该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时,缓存可以直接给出响应,而不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。
图 6. REST 与缓存服务器 (Cache Server)
而对于 SOAP,情况又是怎样的呢?
使用 HTTP 协议的 SOAP,由于其设计原则上并不像 REST 那样强调与 Web 的工作方式相一致,所以,基于 SOAP 应用很难充分发挥 HTTP 本身的缓存能力。
图 7. SOAP 与缓存服务器 (Cache Server)
两个因素决定了基于 SOAP 应用的缓存机制要远比 REST 复杂:
其一、所有经过缓存服务器的 SOAP 消息总是 HTTP POST,缓存服务器如果不解码 SOAP 消息体,没法知道该 HTTP 请求是否是想从服务器获得数据。
其二、SOAP 消息所使用的 URI 总是指向 SOAP 的服务器,如本文例子中的 http://localhost:8182/v1/soap/servlet/messagerouter,这并没有表达真实的资源 URI,其结果是缓存服务器根本不知道那个资源正在被请求,更不用谈进行缓存处理。
关于连接性
在一个纯的 SOAP 应用中,URI 本质上除了用来指示 SOAP 服务器外,本身没有任何意义。与 REST 的不同的是,无法通过 URI 驱动 SOAP 方法调用。例如在我们的例子中,当我们通过
getUserList SOAP 消息获得所有的用户列表后,仍然无法通过既有的信息得到某个具体的用户信息。唯一的方法只有通过 WSDL 的指示,通过调用 getUserByName 获得,getUserList 与 getUserByName 是彼此孤立的。
而对于 REST,情况是完全不同的:通过 http://localhost:8182/v1/users URI 获得用户列表,然后再通过用户列表中所提供的 LINK 属性,例如 <link>http://localhost:8182/v1/users/tester</link>获得 tester 用户的用户信息。这样的工作方式,非常类似于你在浏览器的某个页面上点击某个 hyperlink, 浏览器帮你自动定向到你想访问的页面,并不依赖任何第三方的信息。
总结
典型的基于 SOAP 的 Web 服务以操作为中心,每个操作接受 XML 文档作为输入,提供 XML 文档作为输出。在本质上讲,它们是 RPC 风格的。而在遵循 REST 原则的 ROA 应用中,服务是以资源为中心的,对每个资源的操作都是标准化的 HTTP 方法。
本文主要集中在以上的几个方面,对 SOAP 与 REST 进行了对比,可以看到,基于 REST 构建的系统其系统的扩展能力要强于 SOAP,这可以体现在它的统一接口抽象、代理服务器支持、缓存服务器支持等诸多方面。并且,伴随着 Web Site as Web Services 演进的趋势,基于 REST 设计和实现的简单性和强扩展性,有理由相信,REST 将会成为 Web 服务的一个重要架构实践领域。
接口抽象
RESTful Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 来抽象所有 Web 系统的服务能力,而不同的是,SOAP 应用都通过定义自己个性化的接口方法来抽象 Web 服务,这更像我们经常谈到的 RPC。例如本例中的 getUserList 与 getUserByName 方法。
RESTful Web 服务使用标准的 HTTP 方法优势,从大的方面来讲:标准化的 HTTP 操作方法,结合其他的标准化技术,如 URI,HTML,XML 等,将会极大提高系统与系统之间整合的互操作能力。尤其在 Web 应用领域,RESTful Web 服务所表达的这种抽象能力更加贴近 Web 本身的工作方式,也更加自然。
同时,使用标准 HTTP 方法实现的 RRESTful Web 服务也带来了 HTTP 方法本身的一些优势:
无状态性(Stateless)
HTTP 协议从本质上说是一种无状态的协议,客户端发出的 HTTP 请求之间可以相互隔离,不存在相互的状态依赖。基于 HTTP 的 ROA,以非常自然的方式来实现无状态服务请求处理逻辑。对于分布式的应用而言,任意给定的两个服务请求 Request 1 与 Request 2, 由于它们之间并没有相互之间的状态依赖,就不需要对它们进行相互协作处理,其结果是:Request 1 与 Request 2 可以在任何的服务器上执行,这样的应用很容易在服务器端支持负载平衡 (load-balance)。
安全操作与幂指相等特性(Safety /Idempotence)
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)
一般代理服务器的实现根据 (URI, HTTP Method) 两元组来决定 HTTP 请求的安全合法性。
当发现类似于(http://localhost:8182/v1/users/{username},DELETE)这样的请求时,予以拒绝。
对于 SOAP,如果我们想借助于既有的代理服务器进行安全控制,会比较尴尬,如下图:
图 5. SOAP 与代理服务器 (Proxy Servers)
所有的 SOAP 消息经过代理服务器,只能看到(http://localhost:8182/v1/soap/servlet/messagerouter, HTTP POST)这样的信息,如果代理服务器想知道当前的 HTTP 请求具体做的是什么,必须对 SOAP 的消息体解码,这样的话,意味着要求第三方的代理服务器需要理解当前的 SOAP 消息语义,而这种 SOAP 应用与代理服务器之间的紧耦合关系是不合理的。
关于缓存
众所周知,对于基于网络的分布式应用,网络传输是一个影响应用性能的重要因素。如何使用缓存来节省网络传输带来的开销,这是每一个构建分布式网络应用的开发人员必须考虑的问题。
HTTP 协议带条件的 HTTP GET 请求 (Conditional GET) 被设计用来节省客户端与服务器之间网络传输带来的开销,这也给客户端实现 Cache 机制 ( 包括在客户端与服务器之间的任何代理 ) 提供了可能。HTTP 协议通过 HTTP HEADER 域:If-Modified-Since/Last- Modified,If-None-Match/ETag 实现带条件的 GET 请求。
REST 的应用可以充分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后,该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时,缓存可以直接给出响应,而不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。
图 6. REST 与缓存服务器 (Cache Server)
而对于 SOAP,情况又是怎样的呢?
使用 HTTP 协议的 SOAP,由于其设计原则上并不像 REST 那样强调与 Web 的工作方式相一致,所以,基于 SOAP 应用很难充分发挥 HTTP 本身的缓存能力。
图 7. SOAP 与缓存服务器 (Cache Server)
两个因素决定了基于 SOAP 应用的缓存机制要远比 REST 复杂:
其一、所有经过缓存服务器的 SOAP 消息总是 HTTP POST,缓存服务器如果不解码 SOAP 消息体,没法知道该 HTTP 请求是否是想从服务器获得数据。
其二、SOAP 消息所使用的 URI 总是指向 SOAP 的服务器,如本文例子中的 http://localhost:8182/v1/soap/servlet/messagerouter,这并没有表达真实的资源 URI,其结果是缓存服务器根本不知道那个资源正在被请求,更不用谈进行缓存处理。
关于连接性
在一个纯的 SOAP 应用中,URI 本质上除了用来指示 SOAP 服务器外,本身没有任何意义。与 REST 的不同的是,无法通过 URI 驱动 SOAP 方法调用。例如在我们的例子中,当我们通过
getUserList SOAP 消息获得所有的用户列表后,仍然无法通过既有的信息得到某个具体的用户信息。唯一的方法只有通过 WSDL 的指示,通过调用 getUserByName 获得,getUserList 与 getUserByName 是彼此孤立的。
而对于 REST,情况是完全不同的:通过 http://localhost:8182/v1/users URI 获得用户列表,然后再通过用户列表中所提供的 LINK 属性,例如 <link>http://localhost:8182/v1/users/tester</link>获得 tester 用户的用户信息。这样的工作方式,非常类似于你在浏览器的某个页面上点击某个 hyperlink, 浏览器帮你自动定向到你想访问的页面,并不依赖任何第三方的信息。
总结
典型的基于 SOAP 的 Web 服务以操作为中心,每个操作接受 XML 文档作为输入,提供 XML 文档作为输出。在本质上讲,它们是 RPC 风格的。而在遵循 REST 原则的 ROA 应用中,服务是以资源为中心的,对每个资源的操作都是标准化的 HTTP 方法。
本文主要集中在以上的几个方面,对 SOAP 与 REST 进行了对比,可以看到,基于 REST 构建的系统其系统的扩展能力要强于 SOAP,这可以体现在它的统一接口抽象、代理服务器支持、缓存服务器支持等诸多方面。并且,伴随着 Web Site as Web Services 演进的趋势,基于 REST 设计和实现的简单性和强扩展性,有理由相信,REST 将会成为 Web 服务的一个重要架构实践领域。
发表评论
-
Apache CXF
2014-06-17 10:15 598Apache CXF 编辑 目录 ▪ CXF的关键的设计考虑因 ... -
最全的HTTP状态码,一定要收藏起来
2014-05-17 18:56 427最全的HTTP状态码,一定 ... -
java网站架构设计
2014-05-07 14:27 523java网站架构设计 2012-12- ... -
基于ZooKeeper的Dubbo注册中心
2014-03-05 04:16 782基于ZooKeeper的Dubbo注册中心 Apr102 ... -
Dubbo zookeeper 初探
2014-03-05 03:54 856Dubbo zookeeper 初探 分类: zo ... -
某大型社区网站系统
2014-02-24 20:51 578某大型社区网站系统 分类: 架构设计 2 ... -
Structs2中配置文件详解-不仅要会用更要理解
2014-02-24 20:24 952Structs2中配置文件详解-不仅要会用更要理解 ... -
Spring MVC和Struts2的比较
2014-02-19 11:51 587Spring MVC和Struts2的比 ... -
高性能、高流量Java Web站点打造的最佳实践
2013-12-24 18:49 601高性能、高流量Java Web站点打造的最佳实践 博客 ... -
RESTEasy入门
2013-12-04 14:56 720RESTEasy是JBoss的开源项目之一,是一个REST ... -
优化和架构之服务切分
2013-11-26 08:49 420切分是最基本,且最多 ... -
最佳线程数和QPS以及RT
2013-11-20 08:49 1288最佳线程数和QPS以及RT 博客分类: java ... -
Spring中线程池的应用
2013-11-05 21:50 1149Spring中线程池的应用 您的评价: ... -
架构师成长历程:时刻对新技术保持敏感
2013-10-19 01:19 662架构师是一门建立在科 ... -
对JavaEE中session的理解
2013-10-14 14:50 755博客分类: JavaEE javaJaveEEwebsess ... -
MyBatis批量大数据测试的一些结果
2013-08-23 04:19 2117MyBatis批量大数据测试的一些结果 博客分类 ... -
webservice注解
2013-08-21 12:00 787webservice注解 博客分类: cxf ... -
WebService开发笔记 1 -- 利用cxf开发WebService竟然如此简单
2013-08-21 11:51 882现在的项目中需要用 ... -
隔离级别
2013-07-22 23:14 527隔离级别 自从知道事务的隔离级别已经很长时 ... -
Bean作用域的配置以及 Spring各种注入方式实例 list set map props
2013-07-12 13:15 574Bean作用域的配置以及 Spring各种注入方式实例 li ...
相关推荐
基于REST的软件体系结构风格(Software Architecture Style)称之...按照REST原则设计的软件、体系结构,通常被称为“REST式的”(RESTful),在本文中以下称之为 RESTful Web服务,以便于和基于SOAP的Web服务区别。
RESTful webservice 和 SOAP webserivce 对比及区别
SOAP webserivce 和 RESTful webservice 对比及区别.pdfSOAP webserivce 和 RESTful webservice 对比及区别.pdf
RESTful WebService是比基于SOAP消息的WebService简单的多的一种轻量级Web服务,RESTful WebService是没有状态的,发布和调用都非常的轻松容易。 下面写一个最简单的Hello World例子,以便对RESTful WebService有...
Java restful和webservice接口, WebService有两种方式,一是SOAP方式,二是REST方式。SOAP是基于XML的交互,WSDL也是一个XML文档,可以使用WSDL作为SOAP的描述文件;REST是基于HTTP协议的交互,支持JSON、XML等交互...
基于 cxf 2.7.5 开发的 webservice [soap restful]
启动后访问http://localhost:8080/cxf-ws-restful-spring-server/ws63
什么是REST,符合REST的API叫RESTful 两种SOA接口实现:SOAP(WebService) vs REST
使用jax-ws和jax-rs ,maven、java、spring 分别创建soap类型的webservice和restful类型的webservice,文档附有代码
一个简单的基于SOAP headers的WebService式身份验证 通过通过SOAP Header身份验证。 通过集成windows身份验证。
配置好数据库,放到tomcat访问 http://localhost:8080/Service wsdl:http://localhost:8080/Service/hello?wsdl wsal:http://localhost:8080/Service/rest?_wadl 访问rest实例:...
结合网上的例子,在本地搭建并且跑通了的基于CXF的例子,soap webservice 和 restful webservice的混搭模式. 依赖cxf 3.0.4 测试工具SOAPUI 5.0 服务器 tomcat 7 浏览器 chrome
spring + cxf + restful + soap 方便初学者很快上手。 注解描述 @Path注解的值是一个相对的URI路径,这个路径指定了该Java类的位置,例如/helloworld。在这个URI中可以包含变量,例如可以获取用户的姓名然后作为参数...
Restful风格的WebService正在渐渐取代传统的SOAP, Java 也有很多Restful的框架,很方便简洁,Jersey,restlet,甚至SpringMVC也可以,不得不说Rest让人从Web转型到WebService更容易和方便,当然深入Restful的理论...
调用远程wadl的Webservice代码,请求参数是json,返回结果通过main方法打印
比如:SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ,并且可以在多种传输协议上运行,比如:HTTP、JMS 或者 JBI,CXF 大大简化了 Services 的创建,同时它继承了 XFire 传统,一样可以天然地和 Spring 进行无缝集成。 ...
基于 WebService服务的开发 以Restful风格的编码为主导 案例包括 Ws和Rs两种代码编写 以及包含与Spring整合代码客户端和服务端的实现
kong-plugin-soap2rest 插件,用于将SOAP请求重定向到REST API并将JSON响应转换为SOAP响应。 目录 兼容的Kong版本 港版 测试通过 2.3.x :check_mark_button: 2.2.x :check_mark_button: 2.1.x :check_...
采用spring 结合cxf 发布一个RestFul接口。 http请求,soap均可调用。
按照,我从一个空的 Maven 项目开始,添加所有依赖项和初步配置(Spring Boot Application 主类、WebService 配置等)。 下一个任务是使用传输对象的定义创建 XSD 文件。 为简洁起见,让我们假设传输对象的定义如下...