REST架构风格

REST字面意思是表示性状态转移,它是一种充分利用Http协议的BS架构风格.为什么这么讲呢?我们看看Roy Thomas Fielding博士对于REST机构风格的定义.REST架构风格是一种组合架构风格:
1)REST整体架构上使用CS风格,这种风格其实也是BS架构风格的基础风格;
2)REST在服务端采用无状态架构风格,无状态(面向非连接)也是BS架构风格典型特点,传统的CS架构一般都是有状态的,是面向连接的.
3)缓存风格:在服务端提供必要的缓存风格,以提高系统性能.缓存风格是一种常见的架构设计风格,目的是解决系统各部分之间的由于访问速度差异而导致的部分资源无法充分利用的问题,例如CPU的高速缓存,内存的设置都是这个目的.BS风格和传统CS风格都会采用这种机制.
4)统一接口:统一接口其实是相对的,在不同层次上统一接口的代价也是不同的,层次越低代价越大,层次越高,代价越低.REST架构风格要求在组件层上采用统一架构风格,从而简化整体架构.REST风格中的这种接口统一是针对WEB开发的,目的是简化站内子系统之间和站间系统之间的访问.
5) 分层系统:分层的好处是可以使得每一层的组件仅仅依赖于与之交互的紧邻层,而且分层系统本身就要求对其它层提供服务的接口应该统一而稳定.因此这种风格可以简化系统的复杂性(每一层只需要专注于本层逻辑,而且修改也只会影响紧邻层,不会导致蔓延问题),提高了系统的灵活性(原因非常简单,只要保持稳定的接口,替换和重新实现某一层组件都非常用意),C跟S本身就是分层的,这里的分层风格约束,主要是指S端(C端因为是基于脚步解释,而且多为展示,分层相对受限),而S端的分层可以采用MVC,其中对于M还可以分解为业务逻辑层,数据访问层,数据库访问层.分层风格的缺点是由于层次增加会带来性能上的消耗,需要利用共享缓存来弥补分层所带来的性能上的损失.
6)按需代码:这种风格最大好处在于部署和动态行为方面.采用这种分格,客户端可以根据需要下载代码(JS脚本,Applet,ActiveX等).但这种风格能否实现的前提是客户端可以执行或者解释执行下载的代码.
WEB系统的目的是共享和传递信息,REST风格将所有信息都抽象为一种资源,并给定一个唯一的标识(URI).需要注意的是这里的资源不是一类,而是具体的资源实体或者实体集合,例如对于客户来说,一般情况下不能看作是一种资源,而所有客户,华北地区的客户,客户张三则可以视为一种资源,而且都各自有唯一标识.不人为地通过类型和实现来区分资源的好处是可以简化访问的语义理解,访问者除了需要知道要访问的资源的URI,其余的都不用关心(本质上来讲这其实是有意义编码,无意义编码和混合编码之间的区别).而且URI所代表的资源可以是静态映射的(2010年10月1日的天气)的,也可以是动态映射的(今天的天气).

REST风格通过URI访问得到的信息是自我描述的,包括了信息本身和表示方式(html,xml,媒体数据流等).信息的描述是采用最通用的协议-HTTP(超文本转换协议)来进行的.客户端根据信息的表示解析和展示信息本身.而交互是通过HTTP的几个基本操作(GET,PUT,POST,DELETE)来实现.

一些看法:

1) REST与MVC(至少对于微软的Aspnet MVC而言)架构风格并不矛盾，他们之间并不存在谁替换谁的问题；
2)REST风格非常适合站间或者企业间集成应用，比WebService,Corbra,DCOM,JRMI都要简单通用;
3)如果将URL地址后的参数看作是URL本身的一部分，那么每一个URL都代表一个唯一的资源（URI）,而用/来标识参数和用?部分标识参数其实是等价的,但对外来说,用/要简单些;
4)REST的核心在于充分利用Http协议；
5)REST返回的数据及表示或者动态代码需要客户端解释，有利也有弊，不利的地方当然是性能和“非强类型”；
6)如果采用RESTfull,一个随之而来的是URI泛滥和URI体系表达设计的复杂性问题，因此原作者对此风格的建议是用于粗粒度应用;
7)REST架构风格所假定的资源状态相对简单，并不适合资源状态非常复杂的应用（不是不可以，是不适合）；
8)REST的天生支持分布式架构，其实是Http协议和BS架构风格所决定的；

PS:有些认为有面向URI设计,这跟测试驱动开发一样,都是概念性东西多一些,本质上其实都是面向需求设计.
PS:微软的MVC估计是在Roy博士发表文章之后做的设计,里面带有很强的REST风格.