REST和SOAP的复杂性

Pete对上一篇blog文章的评论已引发出更多的评论。好，让我来尝试回答Pete在他的评论中所提出的问题吧。希望这篇文章能引起更多愉快而有益的讨论。。。­

在我看来，Pete的主要问题是：哪些Web服务用例（use cases）体现了与REST用例的区别？它们各自应当在什么情况下采用?以及增添的Web服务复杂性在什么情况下是合理的？

也许这样的回答太过于简单化了，但我认为这是最好的概括：如果你要用浏览器来显示XML数据，那么就采用REST；如果你要把XML数据传给一个程序来处理，那么就采用SOAP。

关于Amazon.com的Web服务的使用情况是：去年，80%的开发者采用了XML over HTTP版，而20%的开发者采用了SOAP版。这是合理的，因为大多数Amazon.com用户所关心的是“用浏览器访问虚拟店铺时的数据显示”。不过，Amazon.com同时支持这两种风格的“Web服务”，因为也有开发者关注于“把数据传给程序作处理”。（为了明确起见，我将采用Amazon的术语——REST和SOAP Web服务）。

看待REST的一种方式是：它基本上意味着把Web服务请求放在URL里。

下面这个URL是我在Google.com中搜索“Skateboots”时得到的：

http://www.google.com/search?hl=en&ie=UTF-8&q=%22Skateboots%22&btnG=Google+Search

基本上，Google是把我输入Web表单的关键字作为参数放在URL里（URL里还有其他一些关于字符集和即将执行的操作（比如“搜索”）的信息），并根据此URL来执行服务，然后在浏览器中返回结果。Google还会提示我：要搜索的是不是“Skate Boots”（即两个词，而不是我输入的单个词）。如果点击该提示链接的话，将会得到下面的URL：

http://www.google.com/search?hl=en&ie=UTF-8&q=%22Skate+boots%22&spell=1

Amazon.com最近（2004年8月）发布的Web服务第4版继续一如既往地同时支持REST和SOAP请求。目前，有些人会争辩说REST和Web服务是不同的事物；而另一些人则认为，Web服务能做的，用REST也能做。在我看来，它们就像是相同操作的不同格式。

它们之间的区别似乎可以归结为：你是否希望用浏览器来解释结果数据。如果是的话，那么你最好还是采用REST请求（即把参数放在URL里）。但是，如果你要用程序来解释数据的话，你还是应该采用SOAP请求，因为它是用XML消息（而不是URL）来携带参数的。

下面是Amazon为基于REST的Web服务请求定义的格式：

http://webservices.amazon.com/onca/xml?Service=AWSECommerceService
&SubscriptionId=[your subscription ID here]
&Operation=ItemSearch
&SearchIndex=Books
&Keywords=dog
&ResponseGroup=Request,Small

在你获得订购ID之后（不好意思，我还没有体验过获得一个订购ID），你可以把请求参数放在Firefox（或其他浏览器）地址栏中，然后按回车键执行之，并浏览XML结果。这最简单不过了。

但是，如果你要把XML数据传给程序处理的话（可能采用其他传输协议），SOAP请求格式将能够更好地胜任，因为它就是为此而设计的；消息所需的全部都在信封（envelope）里（即不依赖于传输协议的特征，比如固定接口、URL参数等）。如果采用REST请求的话，你得自己编写除在浏览器中显示XML以外的所有代码。而且，你在添加企业应用所需的重要特征（比如安全性、可靠性、事务性等）时，你也必须考虑如何编写相关代码。代码可能很快就会变得相当复杂。

接下来的讨论主要是围绕着开发工具进行的，因为开发工具在使用SOAP（以及WSDL）时是相当重要的。这里的基本问题是：像XMLSpy、Visual Studio、WebLogic Workshop、Artix Developer这样的工具是把工作简单化、还是复杂化了？按照Jeff Webb的说法，如果你要修改自动生成的VB类，采用SOAP会比较困难。如果你只是原封不动地使用SOAP请求，利用生成的代码，那么采用SOAP可能是处理XML的最简单、最直接的方式。

另外，这里还有WSDL的问题——这是REST请求所没有的。在Web上发布一个WSDL文件，可以让你的Web服务加入到一个更大的“生态系统”中，因为大多数Web服务工具包（toolkits）可以导入WSDL，并自动生成SOAP消息、以及处理SOAP消息的代理（proxy）和桩（stub）代码。还有许多工具可以根据现有应用元数据（包括CORBA IDL、COBOL Copybooks、C++和Java类、EJB、COM对象等等）生成WSDLs。

如果你已经在用像Visual Studio或Eclipse这样的集成开发环境（IDE）的话，那么Web服务支持已经内置了。而且，随着更多的WS-*规范获得采纳，工具会增加对它们的支持。比如，IONA的Artix已经支持WS-Security，并能自动生成有关SOAP报头（headers）。我认为这里的原则是：尽可能简单，直至别无更简单的适合者；反之亦然，避免复杂，仅当不得以时。

我认为，随着Web“超越浏览器”继续发展，当它遇到企业应用时，自然要面对更多的复杂性。如果所有任务都能用简单的HTTP接口加URL参数完成的话，那将是完美的。不过，IT界在Web以外需要可靠性保证和事务完整性来解决法律与业务问题，比如确保证券交易订单按照收到的次序被执行、以及验证大宗订单（比如数吨钢材）发出者的身份。而且，IT界很长一段时间都不将发生改变。Web需要适应IT界，最简单的做法就是，集成某些已存在的复杂性。

好，那么请给出评论，开始愉快的讨论吧！