从分布式系统的角度看REST

我和江南白衣并没有去拿SOAP和REST相比来说谁优谁劣，这种比较确实毫无意义。我认为，SOAP偏向于企业应用，REST偏向于互联网应用。但不管偏向什么，你难道不承认REST现在没有安全和事务的标准、规范吗？也许，如果只是提供resource，对REST的事务要求并不大，不就是把resource取下来吗？因为它不涉及到各个resource的联合。

另外，“SOAP对于HTTP的利用是低效的”，也许如此，但是SOAP的设计者并没有将它绑定到HTTP啊，HTTP只是传输通道，而SOAP是通道中的消息内容，也就是说HTTP只是载体。现在的开源Axis2引擎，已经直接支持了SMTP、JMS、RMI了，相信XMPP(Jabber)协议上的支持也不远。附带说一下，XMPP和SOAP某些方面也很类似，譬如都偏向于用message格式来定义语义，而且都可以在不同的传输通道上，如XMPP over socket，over http，gtalk现在是桌面客户端，我相信不久就有web版的gtalk。

而且，SOAP的安全规范主要是在message头上，而不是在传输通道上，如HTTP的session。

确实，SOAP是有些重量级（复杂的namespace和wsdl），但是我们不得不承认，在做遗留系统集成方面，它有其独特的优势，因为在发达国家，很多系统已经运行了几十年，也许还要运行几十年，别人原来投资几个亿的核心业务系统，不可能因为一些技术更新就废弃，它们一般都要被重复利用。

这里的很多同学都有一个明显的误解，为什么这是误解，大家过一段时间看了我们翻译的Fielding先生关于REST的博士论文之后就会明白。

很多同学把REST当作是一种具体的架构，事实上REST并不是一种具体的架构，而是一种架构风格。而SOAP则是一种具体的架构。架构风格和架构在Fielding的论文中都有精确的定义。一种架构风格和这种风格的一种架构的关系就像接口和接口的实例一样。例如：
分布式对象是一种架构风格，而CORBA、DCOM、EJB都是这种风格的一种架构实例。

我的意思是说，SOAP的设计者其实在当初做设计的时候，如果多跟Fielding先生沟通，是完全有可能基于REST架构风格来设计出一种更加有效率的架构和数据格式的，但是他们并没有这样做。SOAP的设计中其实包含了很多出于软件大厂之间利益考虑而作出的折中和妥协，它对HTTP的利用方式，以及它本身的数据格式，都是非常低效的，基本上就是一个最大公分母式的解决方案。因此基于SOAP开发的应用，即使能够有效地集成不同种类的遗留系统，当遇到高并发的场合，其用户可觉察的性能和可伸缩性都是相当差的，这一点只要做过SOAP开发的同学都会有体验。性能和可伸缩性没有了，软件的可用性就完全丧失了，这是你再夸夸其谈用户都不会原谅的事情。

至于楼上同学说的安全性、事务处理，这些关注点基于SOAP的协议能够处理的更好完全是因为历史原因，并不是REST架构风格就无法做这些事情和解决这些问题。只要IBM和M$等大公司认识到了REST的价值，假以时日，这些问题都可以得到解决。这和某人在10年前，理直气壮地批判Java不能做这个不能做那个，其实没有什么本质区别。

其实, Apache CXF(XFire)这个最当红的WebService框架文档里就有RESTful的文档哈：

http://cwiki.apache.org/CXF20DOC/restful-services.html

最近在看SOA方面的一些资料，然而比较遗憾，没有一种构架能提起我的兴趣。它们所承诺的优点，完全达不到让我心动的程度。我相信，没有统一构架，也能很好的处理企业应用遇到的问题，完全不必大张旗鼓地鼓吹哪一种。

REST只是一种架构风格，架构idea，我完全认同。但是这也引出了一个问题，因为架构风格下的具体实现，可能没有一种折中的行业标准，导致互操作性的困难。当然，像RSS这类半REST，也是有规范的。

另外，我并不认同折中和妥协就有什么不好，TCP/IP不都是各大网络公司妥协的结果吗？最初的TCP/IP大概只是Unix平台。没有妥协，就没有互操作。联合就必然意味着妥协。

Google的ATOM好像也没有必要专门搞一套(也许有必要：http://www.answers.com/topic/atom-simple-way-to-read-and-write-information-on-the-web)，但RSS1.1和RSS2.0的差异、Atom确实让RSS客户端开发商大伤脑筋。

大家都知道即时通讯市场的标准是XMPP协议，QQ凭着它的垄断地位，就是不妥协，以至于我们必须在电脑的托盘处放一堆的图标(MSN,gtalk,QQ,Skype...)。gtalk就好多了，基于XMPP行业标准可以和各XMPP客户端兼容，而且标准XMPP服务器可以和gtalk服务器也互通，形成一个统一的即时通讯网络。现在Jive公司著名的XMPP客户端Spark，就可以集成gtalk、AOL、Yahoo、MSN了，非常方便，一个客户端就可以联系到所有这些不同客户端的好友。当然，MSN也不是标准的XMPP，但是至少它公布了其协议。

另外，SOAP的性能和可伸缩性确实差，那么你觉得理想中的SOAP又会是怎样？REST的性能，也许来源于它的过于简洁，剔除了所有不必要的冗余：互操作性规范。

另外，我也承认，SOAP确实把一个简单的问题复杂化了，但实际上，那些复杂性可能只是针对那10％的应用场合。

其实什么标准都无所谓 无论是rss1.0 atom rss2.0都可以经过简单的转换相互调用, 如果我的新闻过去是用rss发布的要转化成atom格式是无需做任何修改的 只需要一个xslt

rest soap 有一点是相通的 那就是用xml接口实现分布和耦合. 所以只要提供xml接口任何语言和框架实现的系统都可以成为restful ws 和ws的一部分.


那些想方设法逃避xml的人还是面对现实吧

Java ONE大概是sun提出的吧？
ONE：Open Network Enviroment，多么伟大的设想！
另外，还有“网格计算”（Grid Computing）http://www.answers.com/Grid%20Computing，也是何其伟大，虽然它可能不是sun提出的。MS只是想着怎么取赚起M$，虽然我们也受益了。

CORBA/RMI/WS/EJB/JMS/MQ，基本思路都一样，对象/内容的序列化/反序列化，不管是二进制或者是字符串，都是一种编码格式，一种协议，只是越来越先进的协议都采用自描述的形式，需要传递数据和元数据，增加了网络流量。RIA/REST把B/S推向了C/S模式，公共的Client=Browser。还处于量变过程。

看了各位大大的讨论，受益良多。
  期待 dlee
   "翻译的Fielding先生关于REST的博士论文"

N天以后再回首，REST的确是一种谁都会写的分布式调用方案。但URI->资源, GET/POST/PUT/DELETE/->CRUD的规定在分布式调用方案里并不重要，本意提供通用的接口定义是好的，但服务本来就不一定要映射到资源增删改查，直接URI->服务标识就好了，不用搞得这么麻烦。

另外，WS的document/literal风格也好多年了，XFire就是默认此风格，老拿它的RPC/Encoding风格说它不是很公平。

写了篇小博：

http://blog.csdn.net/calvinxiu/archive/2007/06/15/1653414.aspx