2008年9月23日,JSR3111.0草案通过了JCP执行委员会的赞成投票 ,这基本意味着它现在已经定稿。
如果将Web看成是服务,那RESTful Web服务的Java规范就是以web services的角度来看待Web。又要经过资源与服务的辨析,在Fielding博士的论文里,有几个地方描述了资源:
数据元素 现代Web实例
资源 一个超文本引用意图指向的概念上的目标
6.2.1 重新定义资源
存在着很多地址对应于一个服务,而不是一个文档 ——创作者可能是有意将读者引导到那个服务,而不是引导到来自预先访问那个服务而获取到的特定的结果。
这与早期的对于资源的定义有了不同,过去资源就是指实体,而现在资源是抽象概念,是概念上的映射,是表示一种语义。
写道
这一句离我们日常开发上的用语最为接近,我马上想到的是Struts,Spring MVC之类的控制器模型,尤其是控制器映射。URL或者URN是资源标识符的现代Web实例,比如sslaowan最新的日志:www.iteye.com/blog/lasted-post,它标识了一个资源,就是sslaowan最新的日志,而这个资源是一种概念上的映射,它将对应于一个映射实现,这个映射实现是运行时中的一个哈希Map,它可能来自于XML映射文件,数据库表或者是注解,通过这个Key/Value数据结构找到对应的处理器(也可以叫控制器【见Spring Reference】)实现。
这和我们用Servlet这样的Java API感觉上是类似的,根据Mapping,可以转向一个具体的文件,或者是转向一个处理器来返回一个响应 (其中可能包含一个表述) 。
那么既然Servlet这样的Java API都是这样做的,跟现在Spring3支持的注解方式的REST,以及CXF、RestEasy这样支持规范的框架,究竟有什么不同或者说是进步呢?
先看看Struts1.2怎么做映射:
<action-mappings> <action path="/getPost" type="org.sample.fourm.GetPostAction" scope="request" > <action path="/blog/edit" name="post" type="org.sample.fourm.PostEditAction" scope="request"> </action>
我们可能会这样写URL:www.iteye.com/getPost.do?id=123获得某个用户的blog列表。然后会使用URL:www.iteye.com/blog/edit.do?id=12334,获得要修改的日志。
由于人们觉得应该将一个功能写在一个Action里,因此使用DispatchAction,加入parameter="method" 在<action path>段中即可。然后通过method=edit|new|list等来实现上述功能。
Spring的做法类似,可以参见http://www.iteye.com/topic/72195
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props> <prop key="/getPost">GetPostAction</prop> </props> </property> </bean>
我们可以通过通配符来使这件事变得更容易,然后Spring把这件事又推进了一步,利用CoC,只要按照“惯例”来写,就无需配置映射了。实际上Rails给出一个缺省的Router原理类似。
之后我们做的事情就是利用HTML支持的Get和POST方法做所有的事情,一种是用Get方式,URL后面有一个用&分隔的请求变量串;一种是通过POST方式,将请求变量放到HTTP体里。Struts和Spring都采用FrontController模式来处理请求,根据映射(ActionMapping或HandlerMapping)来找到相应的处理器或者直接找到文件。
下面对比几个URI:
1 www.iteye.com/blog/123和www.iteye.com/getPost.do?id=123和www.iteye.com/getPost.do?postId=123谁能更好的表示获得用户id为123的用户的日志这个语义.
2 www.iteye.com/blog/123/edit和www.iteye.com/editPost.do?id=12334和www.iteye.com/blog/edit?id=12334和www.iteye.com/editPost.do?postId=12334和www.iteye.com/blog/getPostForEdit/12234(有点像SQL里的select for update)谁能更好的表示获得Post编号为12234的Post并要对它进行修改这个语义?
RoR的标准做法显然是把Blog看成是资源,然后将其他表示请求语义的内容加入到资源标志中,或者是放入到表述中,比如lock(锁定帖子)。
过去的框架都没法做/blog/{userId},/blog/{postId}/edit,或者是/blog/{userId}/post/{date-period}/list这样的映射。现在可以了,关键就是URL模板和参数映射:
Spring 3代码
@RequestMapping(value="/blog/{userId}/posts/{date-period}/list", method=RequestMethod.GET)
public String getPost(@PathVariable("userId") long userId, @PathVariable("date-period") String datePeriod, Model model) {
}
关键问题是,有必要这样做吗?
下面看看REST API和RPC的不同:
Fielding博士对于REST的网络API的定义,即连接器接口的描述如下:
写成API的形式如下:
public [响应的控制数据|[资源元数据]|[表述]] 连接器接口 (请求的控制数据 data,资源标识符 id,[表述] p)
其中控制数据 对应的现代Web实例是:if-modified-since(如果包含了 GET 请求,导致该请求条件性地依赖于资源上次修改日期。 如果出现了此头标,并且自指定日期以来,此资源已被修改,应该反回一个 304 响应代码。 )、cache-control(一个用于定义缓存指令的通用头标。)
表述 包括表述的数据(比如HTML文档,JPEG图片等)和表述的元数据(如媒体类型、最后修改时间)。其中媒体类型就是text/html,image/jpeg之类的。
资源的元数据 对应的现代Web实例是源链接、alternates、vary(一个响应头标,用于表示使用服务器驱动的协商从可用的响应表示中选择响应实体。)在Fielding博士的论文中特意将内容协商作为了一节:
信息字段的值或正常的请求参数(方法/标识符/状态码)之外的某事物,为某种特殊的请求
方法/标识符/状态码的组合改变响应的表述。当这种情况发生时,客户端需要得到通知,这
样当语义透明时一个缓存就能够知道,要为将来的请求使用一个特殊的已缓存响应,而一个
用户代理一旦知道协商的信息对于接收到的响应的影响,就能够提供比正常情况下发送的更
加详细的首选项。HTTP/1.1为这个目的引入了Vary头信息字段。Vary简单地列出了请求头
信息字段的维度(译者注:即可以进行协商的头信息字段的列表),这样响应就能够根据这
些信息发生改变。
另外一个更接近我们日常开发使用的术语的描述:
映射到一个 响应 (由一个状态码、响应头信息字段和有时存在的一个表述组成)。