REST SOAP XML-RPC分析比较

本文的标题“REST与SOAP之比较”确实有些让人误解。REST是表明性状态传输的名称首字母缩写，与其说它是标准，不如说是一种风格。然而，在个人前一篇文章中，正如咱们所讨论的，众多从事Web服务的软件设计师们认为SOAP过分复杂，因而，相似eBay和Google的服务都采用了REST风格的约束来暴露其大量数据。

        我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，不然的话，开发人员很快就会将其抛之脑后。好比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：

　　http://company.com/catalog/description/n1996-01

　　在处理这个请求时，“/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也许是最佳选择。

-------------------------------------------------------------------------------------------------------------------------------------------

http://it.chinawin.net/softwaredev/article-1b70.html

-------------------------------------------------------------------------------------------------------------------------------------------

 

XML Web Service支持三种协议来与用户交流数据。这三种协议分别是：

1． SOAP：Simple Object Access Protocol

2．  HTTP-GET

3．   HTTP-POST

1．首先咱们先来理解一下这三者的大概定义。

在这三种协议中，SOAP是XML Web Service最经常使用到的链接协议。与HTTP相比，SOAP显的更为复杂，但却拥有更强的接受能力。SOAP是一种以XML为基础的协议，它提供一种将数据打包（Packaging）和 编码（Encoding）的方法，以用于网络的数据传输。任意一个用户均可以使用SOAP协议与任何一个XML Web Service进行通讯，甚至于说这个XML Web Service不是创建在.NET 平台上的，好比说Java的，咱们均可以利用SOAP来进行数据传输。所以可见，SOAP也是Language Independent.(语言独立性)

HTTP(Hypertext Transfer Protocol) 已是众所周知的协议了，它是XML Web Service数据传输的标准，这包括了在使用SOAP传输数据的时候。HTTP将SOAP 消息压缩,而后以它的形式进行网络传输。然而当咱们谈及在XML Web Service下使用HTTP-GET和HTTP-POST的时候，咱们实事上在谈有关单独使用HTTP调用XML Web Service中的方法的能力，这里我说的单独使用，指的是不使用SOAP。

在HTTP中，GET 和　POST并非一种协议，它们是能够用来与Web Service交互的几种方法中的其中二种。然而，这二种方法的传送参数和数据的能力使它们变成了一种简单的，很是适合用来调用XML Web Service的工具。

 

2．HTTP-GET 和　HTTP-POST 的比较

这两者最大的区别在于数据是如何与要求的消息捆绑在一块儿的。

HTTP-GET的处理特征以下：

。将数据添加到URL

。利用一个问号（”?”）表明URL地址的结尾与数据的开端。

。每个数据的元素以 名称/值 (name/value)　的形式出现。

。利用一个分号(“;”)来区分多个数据元素。

HTTP-POST的处理特征以下：

。将数据包括在HTTP主体中。

。一样的，数据的元素以 名称/值 (name/value)　的形式出现。

。可是每个数据元素分别占用主体的一行。

从这两者不一样的处理特征，能够看出它们的不一样之处，而你们也能够利用IE打开一个Web Service文件，在页面中，IE会显示出二种的数据的不一样之处。

3．HTTP和SOAP的比较

HTTP-GET 和 HTTP-POST 提供了一个简单的与XML Web Service交互的工具，与SOAP相比，它有如下几点好处：

。 可以很是容易的建立正确的HTTP-GET 和 HTTP-POST消息，当面向的客户是不能使用SOAP的客户时，HTTP-GET 和 HTTP-POST是最好的选择。

。响应HTTP-GET 和 HTTP-POST的消息，并不须要复杂的XML处理。响应之中包括了XML，但它有一个简单的框架并可以轻易的利用通常的技术处理响应。这些特色使HTTP-GET 和 HTTP-POST对于不支持XML的平台来讲，变的异常的有用。

。HTTP-GET 和 HTTP-POST消息比起SOAP消息来讲，更为简单。这有利于提升总体的性能。

然而，有得必有失，有好必有坏，它们也存在不可忽略的缺点：

。不可以利用HTML调用XML Web Service中的以复杂数据类型为参数的方法。

。你能够调用XML Web Service中返回值为复杂数据类型的方法，可是响应将仅包括复杂数据类型中各个区域中的名字/值，而且返回的值并无结构可言。你必须手动的将数据解压缩到WSDL文件。

。在HTTP中，你不能使用reference进行参数的传输。

。使用HTTP与XML Web Service进行交流，不是一个agreed-to工业标准技术。虽然HTTP会在ASP.NET Web Application中与XML Web Service正常工做，但不保证它在其它的环境下正常工做。

 

 

 

 

 

 

现在，Web开发者的可选技术至关之多；从简化的数据库访问技术，到易用的中间件服务包装技术，以及各类有趣的客户端软件等等，包罗万象。全部这些产品和工具，都是为了帮助Web开发者用最快的速度开发出最好的Web应用。

 

然而，拥有大量可选软件方案以及为Web应用的特定部分选用特定方案，都是具备挑战的事；并且，如今Web开发者必须持续跟踪各类不断变化着的标准与方法。

 

举个例子，Web服务技术就有SOAP（Simple Object Access Protocol，简单对象访问协议）和REST（Representational State Transfer，表示性状态转移）这两种方案。它们都是有效的方案，但在具体场合下采用哪一种方案好，这要取决于Web开发者。

 

目前，大部分Web开发者彷佛都了解REST——一种采用标准URI进行调用的方案。REST很容易理解，并且只要是支持HTTP/HTTPS的客户端/服务器就支持它。你能够用HTTP GET方法来执行命令。因此，开发者们感觉到的REST的优点是：开发简单、只需依托现有Web基础设施、以及学习成本低。

然而，SOAP做为一种古老的Web服务技术，短时间内还不会退出历史舞台。并且，随着SOAP 1.2的出现，SOAP印象中的一些缺点已获得改进，采纳率和易用程度也都获得提升。另需注意的是，从W3C SOAP 1.2版开始，SOAP这一缩写再也不表明Simple Object Access Protocol（简单对象访问协议），而是仅仅做为协议名称而已。

 

相对REST而言，SOAP 1.2多出一些开销，不过这些开销也带来了一些好处。首先，SOAP在三个方面离不开XML（Extensible Markup Language，可扩展标记语言）：SOAP信封（envelope）是基于XML的，它定义了消息里有什么以及如何处理它；一套用于数据类型的编码规则；过程调用和响应的规划。SOAP信封由传输协议（HTTP/HTTPS）发出，RPC（Remote Procedure Call，远程过程调用）获得执行，而后一个XML文档随SOAP信封返回。

 

须要注意的是，基于“通用”传输协议是SOAP的一个优势。REST目前基于HTTP/HTTPS；而SOAP可支持任何传输协议，从HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，简单邮件传送协议），甚至JMS（Java Messaging Service，Java消息传递服务）。不过，因为XML较为冗长且解析费时，所以采用XML也成为一个弊端。

不过，对Web开发者来讲的好消息是，目前上述两种方案都是行之有效的方案。REST和SOAP都能解决许多Web方面的问题与挑战，并且在许多状况下，它们各自都能知足开发者的要求，也就是说可互换使用。

但不少人不知道，这两种技术能够混合搭配使用。REST很好理解，且极易上手；不过因为它缺少标准，所以只被看做是一种架构方法。与之相比，SOAP是一个工业标准，它具有良好定义的协议，以及一套良好确立的规则，在大型和小型系统中均有采用。

所以，REST的适用场合包括：

• 有限的带宽和资源 别忘了返回的结构能够采用（由开发者定义的）任何格式。另外，因为REST采用标准的GET、PUT、POST和DELETE动词，所以可被任何浏览器所支持。除此之外，REST还可使用为目前大多数浏览器支持的XMLHttpRequest对象，这为AJAX增色很多。
• 彻底无状态的操做 对于那些需多步执行的操做，REST并不是最佳选择，采用SOAP更合适。可是，若是你须要无状态的CRUD（Create/Read/Update/Delete，建立/读取/更新/删除）操做，那么应采用REST。
• 缓存考虑 若要利用无状态操做的特性，使得信息可被缓存，那么REST是很好的选择。

以上已经覆盖不少方案了，那么，为何还要考虑SOAP呢？正如前述，SOAP比较成熟并且是通过良好定义的，具备完整的规范。而REST只不过是一种方法，对开发未做任何规约；所以，假如你遇到如下场合，那么SOAP是最佳选择：

• 异步处理与调用 若是你的应用须要确保可靠性与安全性，那么请采用SOAP。SOAP 1.2为确保这种操做补充定义了WSRM（WS-Reliable Messaging）等标准。
• 形式化契约 若提供者/消费者双方必须就交换格式取得一致，那么采用SOAP更合适。SOAP 1.2为这种交互提供了严格的规范。
• 有状态的操做 若是应用须要上下文信息与对话状态管理，那么应采用SOAP。SOAP 1.2为此补充定义了WS-Security、WS-Transactions和WS-Coordination等标准。相比之下，REST方法要求开发者本身来实现这些框架性工做。

正如你所看到的，REST和SOAP各自有其用武之地。它们在安全性和传输层等方面有着本身的潜在问题，不过它们都能完成任务，并且在许多状况下，它们都丰富了Web的技术手段。所以，就这一论题，其实最好的原则就是灵活性原则；由于至少在现今的Web开发中，不管面对何种问题，Web开发者们总有办法运用好这两种技术中的一种。