Chinaunix首页 | 论坛 | 博客
  • 博客访问: 275023
  • 博文数量: 155
  • 博客积分: 2865
  • 博客等级: 少校
  • 技术积分: 1580
  • 用 户 组: 普通用户
  • 注册时间: 2006-03-03 12:34
文章分类

全部博文(155)

文章存档

2010年(2)

2008年(2)

2007年(32)

2006年(119)

我的朋友

分类:

2007-04-20 13:24:28

我有这样一个推断,在计算机世界中,但凡那些让开发人员记住的重要概念,都有一个很酷的名称首字母缩写,否则的话,开发人员很快就会将其抛之脑后。比如Ajax、SOAP以及REST就证明了这一点。

  REST能够在计算机领域被广泛采用,它走的道路是不同寻常的。这个术语是由Roy Fielding创造的。Fielding毕业于Irvine市加利福尼亚大学,在他的博士学位论文中第一次提出了REST这个概念。在Web方面,我们必须承认Fielding是非常精通的,他曾经帮助创建HTTP 1.0规范,该规范从1996年开始就为Web提供基本准则。他在Web标准方面非常有经验,这为他的这篇博士论文奠定了坚实的基础。

  Fielding指出,使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件,可以充分利用 Web 的有用特性,万维网(World Wide Web)才能够达到最佳的工作效果。可以这样理解REST——当一个浏览器得到并且显示构成HTML页面的各个元素时,它正在获取资源的当前状态的表现形式。在Fielding的博士论文中,他列举了REST风格的设计约束,并且解释了为什么这些约束能够充分利用Web 的有用特性,使其达到最佳状态,以及这些约束的关键所在。同时,在论文中,他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论,以及这些Web风格是如何导致设计无法利用Web特性的。

  Fielding认为,对于使用HTTP承载应用程序协议穿越防火墙,XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念,结果是,防火墙厂商为了保护系统需要侦察出所承载的协议。由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙,因此,你可以发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为,如果你打算使用HTTP的话,就应该与充分利用HTTP本身的含义。

  REST风格强调,通过有限的操作或者是“动词”以及一个组件之间的标准接口,也就是HTTP协议提供的借口,来提升客户与服务之间的交互。通过为每一个资源分配其自己的URL,来实现灵活性,REST可以调用包含上百个URI的资源类型的客户,其中的关键是REST能够给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应,从而避免了歧义。举个例子,GET只能够简单地返回资源的表现形式,而不能够创建任何其他的内容。

  在Web发展的初期,由于人们都在试验通过收集各种不同来源的元素,从而把Web应用程序融合在一起,有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息,用于页面创建者没有计划到的用途。这种“屏幕抓取”的Web类比表明,REST风格的方法是先于那些更加复杂的Web服务而出现的。

  REST是一种风格而不是一个标准

  你可能会把软件的架构风格当作对上层设计模式的抽象。然而,根据Fielding所说,设计模式的堆砌并不等同于架构风格,因为模式是非常接近于特定问题的。

  由于REST是超文本系统的一种风格,而不是Web服务的,因此,本文的标题“REST与SOAP之比较”就有些让人误解。然而,很多软件设计人员会将其混淆,他们在考虑如何创建Web服务时,会得出这样的结论:SOAP过于复杂,而简单的类似于REST的设计却更加适合。

 

REST与RPC风格之比较

  远程过程调用的架构,是应用在基于XML-RPC或者 RPC风格的SOAP的Web服务中的,它却有着完全不同的风格。客户端发出命令,以使服务做出特定的操作。换句话说,RPC有动词的倾向。

  REST强调资源(名词)有统一的接口以此来对它们寻址,而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构,动词数量是没有限制的。REST说,我们使用四个动词——非常熟悉,HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应,REST使用资源寻址来处理其可变性。

  一个简单的REST举例

  假设我们希望一个Web服务暴露一部分目录,从这个目录中,用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述,用户需要格式化一个GET请求,类似于下面的这个URL:

  

  在处理这个请求时,“/catalog”将映射到一个服务中,之后,通过该服务对“description/n1996-01”进行解释,从而定位资源。在创建响应时,服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下,假定返回格式是HTML或者XML,客户端能够使用它来控制页面的布局。如果要得到图片,那么这个请求将对“/catalog/picture/n1996-01”进行寻址,返回的响应将是图片内容类型(Content-Type)。

  REST的商业应用

  最近几年,大多数Web商业企业开始对REST非常感兴趣。Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。对服务的HTTP GET请求的响应结果是,采用Atom或者是RSS联合格式的XML数据。Google也使用Atom以及POST、PUT和DELETE操作来完成公共协议。eBay服务提供通过使用不同语言工具来访问服务,这些工具包括文档/文字风格的SOAP以及REST风格。

  那么,对于XML-RPC和SOAP所具有的RPC风格而言,REST风格是否是一个具有竞争力的替代者呢?当然,我决不这样认为,在下一篇文章中,我将尽量向大家展现SOAP所向无敌的领域。

 

比较REST和SOAP的“风格”

  REST依赖一套简单的“动词”,把所有的复杂性都转移到了指定资源的“名词”中。与此不同,SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

  在Web服务发展的初期,XML格式化消息的第一个主要用途是,应用于XML-RPC协议,其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中,客户端发送一条特定消息,该消息中必须包括名称、运行服务的程序以及输入参数。相反, REST风格的请求却不关心正在运行的程序是什么,它仅仅请求命名资源。

  XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大,于是就出现了SOAP——其最初的定义是简单对象访问协议。之后,大家逐渐意识到SOAP其实并不简单,而且也不需要必须使用面向对象语言,所以,现在人们只是沿用SOAP这个名称而已。

  XML-RPC只有简单的数据类型集,取而代之,SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时,SOAP也能够利用XML 命名空间,这是XML-RPC所不需要的。如此一来,SOAP消息的开头部分就可以是任何类型的XML命名空间声明,其代价是在系统之间增加了更多的复杂性和不兼容性。

  另外,非常重要一点是,REST是需要请求HTTP的,与其相比,SOAP更具优势,SOAP消息可以由所有能够处理Unicode文本的传输方式来传送,很可惜,这一点通常不被人们所认可。事实是,由于HTTP穿透防火墙的便捷性,以及开发商们对Web非常熟悉,因此,人们还在继续强调着HTTP传输。

  随着计算机行业的觉醒,人们发现了基于XML的Web服务的商业潜力,于是,各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展,其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

  最初,SOAP是作为XML-RPC的扩展而发展起来的,它主要强调的是,通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在,通过不断进步,人们发现了更多的使用SOAP的方式,而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何,要掌握SOAP,了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL

  为了创建一个用于描述Web服务的XML格式化文件,Web服务描述语言(WSDL)标准提供了足够多的细节,以便能够构建出客户端代码,从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容:

  •   用于访问服务的地址信息
  •   用于传送信息的传输协议(例如,通道数)
  •   用于所有可使用功能的名称和接口使用方法
  •   在所有的请求和响应中所使用的数据类型

  2001年3月,W3C推出了WSDL 1.1版本用于讨论,这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本,基本上已经到了尾声。虽然,WSDL通常是用于特定的SOAP服务,但是,从理论说,它是完全可以用于特定的REST风格的GET或者POST操作的。

  能够根据服务的WSDL描述来自动创建客户端和服务器端代码,支持这一功能的开发环境目前使用得很广泛,以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话,大概会出现上百万条相关信息。也有这样的工具,根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高,但是离优化却是越来越远。

  安全与SOAP

  如果企业使用SOAP来传送有价值的信息的话,那么,安全就是最重要的问题。由OASIS组织发起,计算机行业的领导者们已经联合开发了一套标准,称为WS-Security。这个标准对基本的SOAP通信做出了改善,以便能够处理以下几个问题:

  消息机密性——由于拦截HTTP消息的方式非常多,因此,在请求和响应过程中,必须能够对所有重要信息加密。很幸运,现在的加密技术非常先进,我们能够对消息内容进行加密,以保证消息不被修改。

  客户和服务身份——必须能够核实SOAP请求来源的身份。

  结论

  在开发人员的意识里,对于Web服务的开发而言,REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外,现在,有许多集成开发环境能够在现有代码的基础上,依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务,或者你需要一些安全功能如消息签名和加密,那么,SOAP能够确保消息的安全性。另一方面,如果你希望使用简单接口来公布一些信息,而不需要繁琐的处理过程,那么,REST也许是最佳选择。

阅读(1360) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~