上周末在杭州网侠大会做了关于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抽象资源的分布式调用,换句话来说,就是分布式调用是绑定在资源的操作上面的。
通过上面的总结,我们可以做一个直观的对比表格:
[code]分布式架构 协议 调用方式
-------------------------------------------------------
Corba架构 专有二进制协议 对象的CRUD操作
EJB架构 专有二进制协议 对象的CRUD操作
Web Services SOAP协议 RPC方式
REST HTTP协议 对资源的CRUD操作
--------------------------------------------------------[/code]
REST最大的特点是什么呢?[color=red]REST是为通过HTTP协议来进行分布式调用量身定造的架构[/color]
传统上,我们开发一个非分布式的软件系统,使用OO进行建模和架构,无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用,也许我们需要探索更好的面向对象的分布式调用架构。
[color=red]REST是专门为分布式调用设计的架构,在REST里面,分布式是通过对资源的操作来实现的,不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念,资源被映射到相应的一套URL规则上面了。[/color]所以资源只和URL相关,而与具体实现无关,因此REST具有更好的解藕性。在RoR的实现当中,你可以把一些资源直接映射到model对象上面去,也可以不映射到model上面,而完全是由业务逻辑组合的抽象资源。
我们说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抽象资源的分布式调用,换句话来说,就是分布式调用是绑定在资源的操作上面的。
通过上面的总结,我们可以做一个直观的对比表格:
[code]分布式架构 协议 调用方式
-------------------------------------------------------
Corba架构 专有二进制协议 对象的CRUD操作
EJB架构 专有二进制协议 对象的CRUD操作
Web Services SOAP协议 RPC方式
REST HTTP协议 对资源的CRUD操作
--------------------------------------------------------[/code]
REST最大的特点是什么呢?[color=red]REST是为通过HTTP协议来进行分布式调用量身定造的架构[/color]
传统上,我们开发一个非分布式的软件系统,使用OO进行建模和架构,无往而不利。但是分布式对象却显得不那么有效。对于跨进程的调用,也许我们需要探索更好的面向对象的分布式调用架构。
[color=red]REST是专门为分布式调用设计的架构,在REST里面,分布式是通过对资源的操作来实现的,不是像EJB那样通过对象的方法调用来实现的。资源是一种抽象的概念,资源被映射到相应的一套URL规则上面了。[/color]所以资源只和URL相关,而与具体实现无关,因此REST具有更好的解藕性。在RoR的实现当中,你可以把一些资源直接映射到model对象上面去,也可以不映射到model上面,而完全是由业务逻辑组合的抽象资源。