从分布式系统的角度看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上面，而完全是由业务逻辑组合的抽象资源。

是不是面向对象有那么重要么？

第一次听说rest还是听庄表伟录音
关于rest听说挺神的 但是网上资料好像比较少
robbin能不能做个例子呢？

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

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

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

REST给我最大的感触就是将分布式接口进行规范，将处理资源的负担交给客户端，充分的利用了网络终端的计算能力，减轻了服务器的压力。对于使用REST进行开发设计，虽然它简化了接口，但是可能由于思维习惯问题，还无法完全适应。

不同的角度上看问题总是能发现新东西!

   在不同领域看分布式对象的应用是不同的，比如Web Service，现在还不断增加新的WS-*规范群族来补充其在安全，可靠性，事务性等方面的特性。

    所以REST的优点--轻量级的资源CRUD管理，同时也限制了它的应用领域，如应用集成等企业应用领域暂时看来还不适合。

    另外，Corba其实跨平台呀，在C++/Java交互的时候，Corba还是不错的选择。

Most of the us financial companies, investment banks, hedge funds, need not only distributed computing environment, but also go way further to parallel computing. So it's still not 古老架构风格, only more demanding on computing power. In fact, I personally think experience in the distributed environment is almost a must for a job in the financial companies in us, otherwise the compensation would be dramatically lower.

关于REST
弱弱的问一问（不要打我）
使用REST风格设计时候，怎么对权限进行管控啊？
当使用ACTION的时候，我会针对该ACTION进行权限分配。
而一个ACTION一般会对多个数据库表（是否可以翻译为资源）进行CRUD。
如果使用REST设计，是否会将此ACTION分解成多个URL。但是这个时候，在设计权限的时候是否会比较麻烦呢？

dlee，唱个对台戏啊，不要砍我。

其实我们在这行做得越久，越知道自己master的领域只是业界很少一部分，下断言之前，最好加个depends on....起码在我的领域就强烈不同意你的说法，虽然RPC风格(Corba,RMI,EJB，WebService方法调用驱动时)有些时候的确不如基于消息的风格(JMS,WebService文档驱动时，但有些方面也有其优势，还没沦落到被凭吊的地步嘛:)