我们说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抽象资源的分布式调用，换句话来说，就是分布式调用是绑定在资源的操作上面的。

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

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

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

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