对比REST之前和REST之后的URI映射

     2008年9月23日，JSR3111.0草案通过了JCP执行委员会的赞成投票 ，这基本意味着它现在已经定稿。

JSR 311最终草案：RESTful Web服务Java API 写道

JAX-RS是Java中用于实现以HTTP为基础的RESTful Web服务的 基于注解的API。本质上，注解类和方法的信息能让运行时（Runtime）将它们暴露为资源，这种方法和通过Servlet编程模型来暴露类与方法的做 法有很大区别。实现JAX-RS的运行时（Runtime）周旋于HTTP协议和Java类之间，考虑URI、被请求和被接受的内容类型和HTTP方法。

 

    如果将Web看成是服务，那RESTful Web服务的Java规范就是以web services的角度来看待Web。又要经过资源与服务的辨析，在Fielding博士的论文里，有几个地方描述了资源：

 

写道

表5-1 REST的数据元素
数据元素                           现代Web实例
   资源             一个超文本引用意图指向的概念上的目标

 

写道

任何能够被命名的信息都能够作为一个资源 。一个资源是 到一组实体的概念 上的映射 ，而不是在任何特定时刻与该映射相关联的实体本身。

 

写道

6.2 将REST应用于URI
6.2.1 重新定义资源

存在着很多地址对应于一个服务，而不是一个文档 ——创作者可能是有意将读者引导到那个服务，而不是引导到来自预先访问那个服务而获取到的特定的结果。

    这与早期的对于资源的定义有了不同，过去资源就是指实体，而现在资源是抽象概念，是概念上的映射，是表示一种语义。

    写道

REST达到了这个目标，通过将一个资源定义为创作者想要标识的语义，而不是对应于创建这个引用时的那些语义的值。然后留给创作者来保证所选择的这个标识符确实真正标识出了他所想要表达的语义。

写道

将“资源”定义为一个URI标识了一个概念，而不是标识了一个文档。

 

 

写道

资源 是一种概念 上的映射 ——服务器接收到标识符（标识这个映射），将它应用于当前的映射实现（mapping implementation，通常是与特定集合相关的树的深度遍历和/或哈希表的组合）上，以发现当前负责处理该资源的处理器实现，然后处理器实现基于请求的内容选择适当的动作+响应。

 

    这一句离我们日常开发上的用语最为接近，我马上想到的是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博士的论文中特意将内容协商作为了一节：

 

写道

抢先式（服务器驱动（server-driven）的）协商发生在以下情况：当服务器根据请求头
信息字段的值或正常的请求参数（方法/标识符/状态码）之外的某事物，为某种特殊的请求
方法/标识符/状态码的组合改变响应的表述。当这种情况发生时，客户端需要得到通知，这
样当语义透明时一个缓存就能够知道，要为将来的请求使用一个特殊的已缓存响应，而一个
用户代理一旦知道协商的信息对于接收到的响应的影响，就能够提供比正常情况下发送的更
加详细的首选项。HTTP/1.1为这个目的引入了Vary头信息字段。Vary简单地列出了请求头
信息字段的维度（译者注：即可以进行协商的头信息字段的列表），这样响应就能够根据这
些信息发生改变。

 

    另外一个更接近我们日常开发使用的术语的描述：

 

写道

所有资源 都会将一个请求 （由方法、标识符、请求头信息和有时存在的一个表述组成）
映射到一个响应 （由一个状态码、响应头信息字段和有时存在的一个表述组成）。