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开发者们总有办法运用好这两种技术中的一种。