转: Rest简介及Spring实现

一 Roy Fielding

2000年Rest被Roy Fielding提出来的,我对Roy Fielding的印象有以下几个.

一是RoyFielding做为Http协议的起草者,在Http协议发布没多久跳起来说这个世界上很多人对于Http的使用是错误的,所以他说大家应该用Rest.

二是没多久RoyFielding做为Rest思想的启蒙者,在Rest被人接受并被广泛使用没多久跳起来说这个世界上很多人对Rest的使用是错误的..

所以我在PPT上选了柏拉图的一句话做为副标题,"思想永远是宇宙的统治者".

二 Rest

Rest本身的内容比我想象的多的多,大致列出来几个关键点如下:

1.满足以下的Constraints:

1. Client–server
2. Stateless
3. Cacheable
4. Layered system
5. Code on demand (optional)
6. Uniform interface

2.设计接口时候的原则

1. Identification of resources
2. Manipulation of resources through these representations
3. Self-descriptive messages
4. Hypermedia as the engine of application state

3.Rest希望实现的目标

1. Scalability of component interactions
2. Generality of interfaces
3. Independent deployment of components
4. Intermediary components to reduce latency, enforce security and encapsulate legacy systems

以上内容都摘自Wiki,稍微整理了一下.感觉以上的内容都很深刻,所以我简单的列出来了我认为理解Rest的重要的地方.

4.Rest对于我们来说

写道

Every Things is a Resource. 
Every Resouce has a ID. 
We Can Use Http Meothod(Get/Post/Put/Delete) Handle Resource.

简单说,再设计接口的时候,

第一个想到的是,我要提供的资源是什么.

第二个想到的是,这个资源的展现形式是什么.

第三个想到的是,这个资源上封装的操作是什么

我觉得这些就足够了.Rest和Soap比有太多的好处了,还有利于SEO(感谢搜索组的两位大神说到两点,一个是Url Path本身占的权重比Parameters高,一个是Url链接本身的权重就比较高.)

如果是设计一个键盘精灵的接口的话(之前博客中提到过键盘精灵,这里的主要的功能是查找拼音中以"Q"开头的产品列表),仿照前段时间四处流行的对比手法写出来三种不同风格的Url接口设计

写道

普通风格 /prompt/list.do?query=g&count=10&searchFrom=product

文艺风格 
/prompt/product/g/10

2B风格 /?method=getProductPromt&query=g&count=10&searchFrom=product

这时候已经有很多人在争论Rest有没有用处,还有不少人在讨论Rest的适用场景了,还有人问到比较实际的问题,比如说多参数怎么解决.

我觉得Rest本身提供的是一种方式,怎么样让这种方式变得更艺术还真的取决于你怎么去使用他.设计Rest的接口更是一种艺术形式,最简单的例子,我要看一个人的某个时间段发表的文章列表,可能会有以下几种设计方式:

1. /person/xdyl/20000101-20000202

2. /person/xdyl/start/20000101/end/20000202

3./person/xdyl?start=20000101&end/20000202

4./person/xdyl/20000101/20000202/

哪种方式好就看个人喜好了吧.搜了一下SpringMVC也没看到有这种解决方案,之前还以为会有/{a}-{b}/这样的方式.

如果其他的朋友有好的解决方案还请多指点.

三 Spring MVC实现.

我觉得Spring MVC的实现很简单.大概牵涉到两个地方.

1.Spring 本身怎么支持从Path中获取变量的.

2.系统怎么区分一个请求应该被Spring拦截到还是应该被直接访问的静态资源

第一个问题很简单.贴段代码如下:

1. @Controller
2. @RequestMapping(value = "/contact")
3. public class ContactController {
4. private static final Log log = LogFactory.getLog(ContactController.class);
5. @RequestMapping(value = "/{contact}", method = RequestMethod.GET)
6. public String getContactdetail(@PathVariable Long contact, Model model) {
7. Contact c = this.contactService.getContact(contact);
8. if (c == null) {
9. c = new Contact();
10. }
11. model.addAttribute("code", 0);
12. model.addAttribute("contact", c);
13. return "/contact/detail/jmodel";
14. }
15. }

增删改查分别修改"method "以对应Http的四种方法(Post,Delete,Put,Get)就好了.

变量直接通过@PathVariable 就可以拿到.

第二个问题我理解起来也很简单.用UrlRewriter将所有的请求分成两种.动态请求加一个前缀"/app/",配置Spring的拦截器只拦截这种请求. 静态资源以前缀"/r/"开始,请求路径不变.

这样任何一个请求都会乖乖的分成两部分,是以"/r/"开始的就不会走Spring,不是以"/r/"开头全转成"/app/",交给Spring处理.

主要配置如下

web.xml 写道

<filter-mapping> 
<filter-name>UrlRewriteFilter</filter-name> 
<url-pattern>/*</url-pattern> 
</filter-mapping> 
<!--Spring只拦截/app/的请求--> 
<servlet-mapping> 
<servlet-name>dispatcher</servlet-name> 
<url-pattern>/app/*</url-pattern> 
</servlet-mapping>

urlrewrite.xml 写道

<urlrewrite default-match-type="wildcard"> 
<rule> 
<from>/r/**</from> 
<to>/r/$1</to> 
</rule> 
<rule> 
<from>/**</from> 
<to>/app/$1</to> 
</rule> 
<outbound-rule> 
<from>/app/**</from> 
<to>/$1</to> 
</outbound-rule> 
</urlrewrite> 

UrlRewrite可以用其它有同样功能的任意代替,Apache神马的最讨厌了.

最后附上我用到的UrlRewriter的Pom文件.不记得在哪儿看到的了,先贴上来再说.

pom.xml 写道

<dependency> 
<groupId>org.tuckey</groupId> 
<artifactId>urlrewritefilter</artifactId> 
<version>3.1.0</version> 
</dependency>

Over,这个东西不是一个很详细的Spring配置说明.我记得第一次配的时候还是出了不少问题的.不过我觉得源码如果公开的话就什么问题都么有了~

等等看什么时候可以把Labs的源码公开了.