从分布式系统的角度看REST

上周末在杭州网侠大会做了关于REST的演讲。会后经过一些交流，特别是今天在msn上面和dlee的交流，感觉自己对于REST的理解更深入了一层。

我们说REST架构风格，从REST具备的内在特征来说，它包括了这些特征：

1、基于HTTP的资源
2、以HTTP协议去操作
3、数据和表象分离

但是如果我们换一个角度，即分布式应用系统的角度来看，我们会有一些更有意思的结论：

分布式应用系统的架构，经历了好几代的变迁，我们来简单回顾一下：

1、基于CORBA协议的C++中间件时代
CORBA时代我还在上学，基本上没有怎么接触过Corba编程。曾经有一次我提供EJB培训的客户，正在进行传统Corba架构向EJB2架构迁移，通过和他们的交流，对Corba多了一些了解。当时就感叹，和EJB2相比，Corba实在太难用了。Corba时代在1998年EJB1.0发布以后，就逐渐淡出历史舞台了。

2、基于RMI/IIOP协议的EJB时代
这个时代开始于1998年，到现在基本上已经划上了句号。其实在EJB出现以前，在1996年Microsoft发布WindowsNT4.0以后，Microsoft当时也提出了自己的分布式架构，即MTS，但是MTS的光辉被随后出现的伟大的EJB技术彻底击败，此后，就拉开了Java的应用服务器时代，BEA也是在这个时代的转折点成长起来的。

不管是Corba，还是EJB，都有一些共同点：
1) 通过专有的网络协议通讯
2) 不能跨平台调用
3) 通过分布式对象调用来实现分布式架构，换句话来说就是，分布式架构是绑定在面向对象的机制上的

分布式对象架构的缺陷在EJB2时代被充分暴露了出来，乃至于Martin Folwer在《企业应用架构模式》当中强调，分布式调用的第一原则就是不要分布式。更多关于EJB2分布式对象架构的缺陷在Rod Johnson的《J2EE without EJB》当中被剖析的更加清楚。

3、基于SOAP协议的Web Services时代
这个时代始于2001年Microsoft公司推出dotnet平台，整个行业开始鼓吹Web Services。中间经历了一次低潮之后，在IBM,BEA成功的联手炒作SOA之后，再次王者归来。

web services有一些明显不同于Corba和EJB分布式对象架构的特征：
1) 通过标准SOAP协议通讯，一般走HTTP通道
2) 能够跨平台调用
3) 通讯格式是xml文本，而不是二进制数据格式
4) 通过RPC机制来实现分布式调用，而不是通过面向对象机制实现分布式调用

web services的优点和缺点都非常突出，这个不是本文的要点，不做具体分析。这里唯一要强调的是SOAP协议并不依赖于HTTP。事实上SOAP协议可以走很多底层协议，例如SMTP协议，Jabber协议等等。

REST也是一种分布式系统的架构风格，那么REST和上面这些分布式架构有哪些明显的区别呢？
1) REST走的是HTTP协议，并且充分利用或者说极端依赖HTTP协议
Corba和EJB是采用专有的二进制协议，SOAP可以但不依赖HTTP，并且仅仅使用HTTP POST。
2) REST是基于HTTP抽象资源的分布式调用，换句话来说，就是分布式调用是绑定在资源的操作上面的。

通过上面的总结，我们可以做一个直观的对比表格：

分布式架构       协议             调用方式
-------------------------------------------------------
Corba架构        专有二进制协议      对象的CRUD操作
EJB架构          专有二进制协议      对象的CRUD操作
Web Services     SOAP协议            RPC方式
REST             HTTP协议            对资源的CRUD操作
--------------------------------------------------------

REST最大的特点是什么呢？REST是为通过HTTP协议来进行分布式调用量身定造的架构

传统上，我们开发一个非分布式的软件系统，使用OO进行建模和架构，无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用，也许我们需要探索更好的面向对象的分布式调用架构。

REST是专门为分布式调用设计的架构，在REST里面，分布式是通过对资源的操作来实现的，不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念，资源被映射到相应的一套URL规则上面了。所以资源只和URL相关，而与具体实现无关，因此REST具有更好的解藕性。在RoR的实现当中，你可以把一些资源直接映射到model对象上面去，也可以不映射到model上面，而完全是由业务逻辑组合的抽象资源。

评论

48 楼 Lordaeron 2007-06-16  

dlee 写道

Lordaeron 写道

你知你每天在打的電話的計費系統是用什麼的嗎?
請問EJB 的底層是什麼? 它用什麼protocol?

你是想说用的是CORBA或者EJB吧？你说的是哪一家公司的交换机产品呢？你该不是想说全世界的交换机计费系统都使用CORBA或者EJB吧？
你知道我以前是做什么的？我以前是做7号信令的。电话计费系统虽然没有亲自做过，还算略微有些了解吧。

我不想知你以前是做什麼的.
我也沒說過全部的計費系統都跑Corba.
我只是要回應, 不要亂講話!!
不知道, 就別整天在吹說ooxx已死.

distributed system 的framework, 小的不講, 大的就不止
Corba,DCOM 和J2EE 了. CICS, IMS, TUXEDO 等等.

另外, CORBA 和EJB 是不對level 的東西, 不要拿來比較.
corba 是架構的名字, 和J2EE 一樣.
EJB 要比的是CCM.
所以我認為你的<还算略微有些了解> 是真的太<略微>了.

47 楼 dlee 2007-06-15  

Lordaeron 写道

你知你每天在打的電話的計費系統是用什麼的嗎?
請問EJB 的底層是什麼? 它用什麼protocol?

你是想说用的是CORBA或者EJB吧？你说的是哪一家公司的交换机产品呢？你该不是想说全世界的交换机计费系统都使用CORBA或者EJB吧？
你知道我以前是做什么的？我以前是做7号信令的。电话计费系统虽然没有亲自做过，还算略微有些了解吧。

46 楼 江南白衣 2007-06-15  

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

45 楼 Lordaeron 2007-06-14  

dlee 写道

robbin，如果作为一个全面的分析的话，似乎还应该包括M$的DCOM。CORBA/DCOM/EJB都是分布式对象架构风格的不同实例。

Java的远程调用机制，除了EJB以外，还有Hessian和Burlap等等轻量级的协议，除了EJB以外，其他的协议的架构风格都不是分布式对象。没有几个人真正需要分布式对象，这是毫无疑问的。

我的看法是：分布式对象的年代已经过去了，将会成为一个供人凭吊的古老架构风格。

你知你每天在打的電話的計費系統是用什麼的嗎?
請問EJB 的底層是什麼? 它用什麼protocol?

44 楼 Lordaeron 2007-06-14  

這邊大談Corba/EJB/DCOM 的人, 有誰是這三個item 都
做過的?
還是只是理論家而已

43 楼 Terry_Y 2007-06-12  

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

42 楼 imjl 2007-06-02  

同意dlee看法。

41 楼 whisper 2007-06-02  

是否面向对象没什么意义
直接RPC-API也不是啥坏事

40 楼 CurrentJ 2007-05-29  

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

39 楼 zwchen 2007-05-29  

ray_linn 写道

每次的伟大光辉都是从microsoft开始,sun是个技术跟随者而已.

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

38 楼 ray_linn 2007-05-29  

dlee 写道

robbin，如果作为一个全面的分析的话，似乎还应该包括M$的DCOM。CORBA/DCOM/EJB都是分布式对象架构风格的不同实例。

Java的远程调用机制，除了EJB以外，还有Hessian和Burlap等等轻量级的协议，除了EJB以外，其他的协议的架构风格都不是分布式对象。没有几个人真正需要分布式对象，这是毫无疑问的。

我的看法是：分布式对象的年代已经过去了，将会成为一个供人凭吊的古老架构风格。

你还漏掉了 .net remoting.

37 楼 ray_linn 2007-05-29  

每次的伟大光辉都是从microsoft开始,sun是个技术跟随者而已.

36 楼 winterwolf 2007-05-29  

zwchen 写道

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

另外，我并不认同折中和妥协就有什么不好，TCP/IP不都是各大网络公司妥协的结果吗？最初的TCP/IP大概只是Unix平台。没有妥协，就没有互操作。联合就必然意味着妥协。
Google的ATOM好像也没有必要专门搞一套，RSS1.1和RSS2.0的差异也让RSS客户端开发商大伤脑筋。

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

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


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

35 楼 zwchen 2007-05-28  

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％的应用场合。

34 楼 partech 2007-05-28  

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

33 楼 江南白衣 2007-05-28  

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

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

32 楼 dlee 2007-05-28  

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

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

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

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

31 楼 zwchen 2007-05-28  

引用

REST设计的初衷本来就不是做EAI，它设计的初衷是做什么，相信大家都完全有能力读懂Fielding论文。将REST的弱项与SOAP设计的初衷和强项相比，就好像让张飞和织女来比绣花一样，这样得出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），但是我们不得不承认，在做遗留系统集成方面，它有其独特的优势，因为在发达国家，很多系统已经运行了几十年，也许还要运行几十年，别人原来投资几个亿的核心业务系统，不可能因为一些技术更新就废弃，它们一般都要被重复利用。

30 楼 dlee 2007-05-28  

我们还是需要将严肃的技术讨论与大公司的市场炒作区分开。崇拜Bill Gates是一回事情，不能因为崇拜Bill Gates就认为M$的一切技术永远都是伟大光明正确的。对于这样的同学，基本上不可能与他开展任何严肃的技术讨论。

SOAP对于HTTP的利用是低效的，这是毫无疑问的。SOAP的设计者当时并不理解HTTP的设计意图，仅仅将HTTP当作一种传输协议而已。所以Fielding在其论文的最后一章，专门指出HTTP并不是一种传输协议。这是说给谁听的呢？我认为很大程度上是说给SOAP的设计者听的。

29 楼 jinfeng105 2007-05-28  

本月初，国际标准联盟OASIS宣布，其成员已经正式批准Web服务事务处理(WS-Transaction)1.11版本成为OASIS标准，代表着其已经成为最高等级的标准。(http://searchwebservices.techtarget.com.cn/comment/10/3342510.shtml)
但这里还是WS-*开头的,SOAP是WS-*基础,而且相关技术、规范、标准都在发展中。有权威组织的支持,有IBM,IONA,微软,Oarcel等国际大公司的支持,SOA不火都不行.