97久久超碰,久久精品亚洲一区二区三区浴池 ,久草视频视频在线播放

REST in Spring 3: @MVC

Eric.Zhou — Thu, 24 Dec 2009 11:53:00 GMT

In the last couple of years, REST has emerged as a compelling alternative to SOAP/WSDL/WS-*-based distributed architectures. So when we started to plan our work on the next major release of Spring – version 3.0, it was quite clear to us that we had to focus on making the development of 'RESTful' Web services and applications easier. Now, what is and isn't 'RESTful' could be the topic of a whole new post all together; in this post I'll take a more practical approach, and focus on the features that we added to the @Controller model of Spring MVC.

A Bit of Background

Ok, I lied: there is some background first. If you really want to learn about the new features, feel free to skip to the next section.

For me, work on REST started about two years ago, shortly after reading the highly recommended book RESTful Web Services from O'Reilly, by Leonard Richardson and Sam Ruby. Initially, I was thinking about adding REST support to Spring Web Services, but after working a couple of weeks on a prototype, it became clear to me that this wasn't a very good fit. In particular, I found out that I had to copy most of the logic from the Spring-MVC DispatcherServlet over to Spring-WS. Clearly, this was not the way to go forward.

Around the same time we introduced the annotation-based model of Spring MVC. This model was clearly an improvement to the former, inheritance-based model. Another interesting development at that time was the development of the JAX-RS specification. My next attempt was to try and merge these two models: to try and combine the @MVC annotations with the JAX-RS annotations, and to be able to run JAX-RS applications within the DispatcherServlet. While I did get a working prototype out of this effort, the result was not satisfactory. There were a number of technical issues which I won't bore you with, but most importantly the approach felt 'clunky' and unnatural for a developer who was already used to Spring MVC 2.5.

Finally, we decided to add the RESTful functionality to features to Spring MVC itself. Obviously, that would mean that there would be some overlap with JAX-RS, but at least the programming model would be satisfactory for Spring MVC developers, both existing and new ones. Additionally, there are already three JAX-RS implementations offering Spring support (Jersey, RESTEasy, and Restlet). Adding a fourth to this list did not seem a good use of our valuable time.

RESTful features in Spring MVC 3.0

Now, enough of the background, let's look at the features!

URI Templates

A URI template is a URI-like string, containing one or more variable names. When these variables are substituted for values, the template becomes a URI. For more information, see the proposed RFC.

In Spring 3.0 M1, we introduced the use of URI templates through the @PathVariable annotation. For instance:

 
@RequestMapping("/hotels/{hotelId}") 
public String getHotel(@PathVariable String hotelId, Model model) { 
    List hotels = hotelService.getHotels(); 
    model.addAttribute("hotels", hotels); 
    return "hotels"; 
}

When a request comes in for /hotels/1, that 1 will be bound to the hotelId parameter. You can optionally specify the variable name the parameter is bound to, but when you compile your code with debugging enabled that is not necessary: we infer the path variable name from the parameter name.

You can also have more than one path variable, like so:

 
@RequestMapping(value="/hotels/{hotel}/bookings/{booking}", method=RequestMethod.GET) 
public String getBooking(@PathVariable("hotel") long hotelId, @PathVariable("booking") long bookingId, Model model) { 
    Hotel hotel = hotelService.getHotel(hotelId); 
    Booking booking = hotel.getBooking(bookingId); 
    model.addAttribute("booking", booking); 
    return "booking"; 
}

This would match requests like /hotels/1/bookings/2, for instance.

You can also combine the use of Ant-style paths and path variables, like so:

 
@RequestMapping(value="/hotels/*/bookings/{booking}", method=RequestMethod.GET) 
public String getBooking(@PathVariable("booking") long bookingId, Model model) { 
    ... 
}

and you can use data binding, too:

 
@InitBinder
public void initBinder(WebDataBinder binder) { 
    SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd"); 
    binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false)); 
} 
  
@RequestMapping("/hotels/{hotel}/dates/{date}") 
public void date(@PathVariable("hotel") String hotel, @PathVariable Date date) { 
    ... 
}

The above would match /hotels/1/dates/2008-12-18, for instance.

Content Negotiation

In version 2.5, Spring-MVC lets the @Controller decide which view to render for a given request, through its View, view name, and ViewResolver abstractions. In a RESTful scenario, it is common to let the client decide the acceptable representations, via the Accept HTTP header. The server responds with the delivered representation via the Content-Type header. This process is known as content negotiation.

One issue with the Accept header is that is impossible to change it in a web browser, in HTML. For instance, in Firefox, it's fixed to

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

So what if you want to link to a PDF version of a particular resource? Looking at the file extension is a good workaround. For example, http://example.com/hotels.pdf retrieves the PDF view of the hotel list, as does http://example.com/hotels with an Accept header of application/pdf.

This is what the ContentNegotiatingViewResolver does: it wraps one or more other ViewResolvers, looks at the Accept header or file extension, and resolves a view corresponding to these. In an upcoming blog post, Alef Arendsen will show you how to use the ContentNegotiatingViewResolver.

Views

We also added some new Views to Spring MVC, particularly:

the AbstractAtomFeedView and AbstractRssFeedView, which can be used to return an Atom and RSS feed,
the MarshallingView, which can be used to return an XML representation. This view is based on the Object/XML Mapping module, which has been copied from the Spring Web Services project. This module wraps XML marshalling technologies such as JAXB, Castor, JiBX, and more, and makes it easier to configure these within a Spring application context,
the JacksonJsonView, for JSON representations of objects in your model. This view is actually part of the Spring JavaScript project, which we'll talk about more in a future blog post.

Obviously, these work great in combination with the ContentNegotiatingViewResolver!

HTTP Method Conversion

Another key principle of REST is the use of the Uniform Interface. Basically, this means that all resources (URLs) can be manipulated using the same four HTTP method: GET, PUT, POST, and DELETE. For each of methods, the HTTP specification defines exact semantics. For instance, a GET should always be a safe operation, meaning that is has no side effects, and a PUT or DELETE should be idempotent, meaning that you can repeat these operations over and over again, but the end result should be the same.

While HTTP defines these four methods, HTML only supports two: GET and POST. Fortunately, there are two possible workarounds: you can either use JavaScript to do your PUT or DELETE, or simply do a POST with the 'real' method as an additional parameter (modeled as a hidden input field in an HTML form). This latter trick is what the HiddenHttpMethodFilter does. This filter was introduced in Spring 3.0 M1, and is a plain Servlet Filter. As such, it can be used in combination with any web framework (not just Spring MVC). Simply add this filter to your web.xml, and a POST with a hidden _method parameter will be converted into the corresponding HTTP method request.

As an extra bonus, we've also added support for method conversion in the Spring MVC form tags. For example, the following snippet taken from the updated Petclinic sample:

 
<form:form method="delete"> 
    <p class="submit"><input type="submit" value="Delete Pet"/>p> 
form:form>


will actually perform an HTTP POST, with the 'real' DELETE method hidden behind a request parameter, to be picked up by the HiddenHttpMethodFilter. The corresponding @Controller method is therefore:

 

1.@RequestMapping(method = RequestMethod.DELETE) 
2.public String deletePet(@PathVariable int ownerId, @PathVariable int petId) { 
3.    this.clinic.deletePet(petId); 
4.    return "redirect:/owners/" + ownerId; 
5.}


ETag support
An ETag (entity tag) is an HTTP response header returned by an HTTP/1.1 compliant web server used to determine change in content at a given URL. It can be considered to be the more sophisticated successor to the Last-Modified header. When a server returns a representation with an ETag header, client can use this header in subsequent GETs, in a If-None-Match header. If the content has not changed, the server will return 304: Not Modified.
In Spring 3.0 M1, we introduced the ShallowEtagHeaderFilter. This is a plain Servlet Filter, and thus can be used in combination any web framework. As the name indicates, the filter creates so-called shallow ETags (as opposed to a deep ETags, more about that later). The way it works is quite simple: the filter simply caches the content of the rendered JSP (or other content), generates a MD5 hash over that, and returns that as a ETag header in the response. The next time a client sends a request for the same resource, it use that hash as the If-None-Match value. The filter notices this, renders the view again, and compares the two hashes. If they are equal, a 304 is returned. It is important to note that this filter will not save processing power, as the view is still rendered. The only thing it saves is bandwith, as the rendered response is not sent back over the wire.
Deep ETags are a bit more complicated. In this case, the ETag is based on the underlying domain objects, RDMBS tables, etc. Using this approach, no content is generated unless the underlying data has changed. Unfortunately, implementing this approach in a generic way is much more difficult than shallow ETags. We might add support for deep ETags in a later version of Spring, by relying on JPA's @Version annotation, or an AspectJ aspect for instance.
And more!
In a following post, I will conclude my RESTful journey, and talk about the RestTemplate, which was also introduced in Spring 3.0 M2. This class gives you client-side access to RESTful resources in a fashion similar to the JdbcTemplate, JmsTemplate, etc.


Similar Posts

    REST in Spring 3: RestTemplate
    
Adding an Atom view to an application using Spring's REST support
    
Pluggable styling with SpringSource Slices
    
AOP Context Binding With Named Pointcuts
    
Annotated Web MVC Controllers in Spring 2.5 





原文地址�Q�http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/

Eric.Zhou 2009-12-24 19:53 发表评论



Spring MVC Annotation & Convention Over Configuration
Eric.Zhou — Wed, 07 Jan 2009 13:43:00 GMT
Spring MVC在��用annotation�q�行配置controller时候要注意�Q�两�U�urlmapping的模式不能同时��用，如果使用annotation��׃��能再配置urlmapping了�?/p>
-servlet.xml如下�Q?br />



  xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"

  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
 

 

 



 

 



   

   

 

 

  

   org.springframework.web.servlet.view.JstlView

  

  

     /jsp/ 

  

  

   .jsp

  

 






package com.founder.action;
import org.springframework.stereotype.Controller;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.servlet.mvc.multiaction.MultiActionController;




@Controller

@RequestMapping

public class HelloController{

 @RequestMapping

 public String world(){

  String name = "Eric";

  System.out.println("name is = " + name);

  return "hello";

 }

 

 @RequestMapping

 public String test() {

  String name = "test";

  System.out.println("name is = " + name);

  return "test";

 }

 

}



Eric.Zhou 2009-01-07 21:43 发表评论


深入���出REST[转蝲]
Eric.Zhou — Thu, 27 Nov 2008 08:05:00 GMT
作�?Stefan Tilkov译�?苑永�?/strong> 发布�?2007�q?2�?5�?下午10�?0�?

不知你是否意识到�Q�围�l�着什么才是实现异构的应用到应用通信�?#8220;正确”方式�Q�一��Z��论正�q�行的如火如��|��虽然当前��L��的方式明昑֜�集中在基于SOAP、WSDL和WS-*规范的Web Services领域�Q�但也有���数人用�l�小但洪亮的声音��d��说更好的方式是REST�Q�表�q�性状态�{�U�（REpresentational State Transfer�Q�的����U�。在本文中，我不会涉及争论的话题�Q�而是���试对REST和RESTful HTTP应用集成做实用性的介绍。以我的�l�验�Q�有些话题一旦触及就会引来众多的讨论�Q�当涉及到这斚w��话题的时候，我会深入详细地阐�q��?/p>
REST关键原则
大部分对REST的介�l�是以其正式的定义和背景作�ؓ开场的。但�q�儿且先按下不表�Q�我先提��Z��个简单扼要的定义�Q�REST定义了应该如何正���地使用�Q�这和大多数人的实际使用方式有很大不同）Web标准�Q�例如HTTP和URI。如果你在设计应用程序时能坚持REST原则�Q�那���预�C�着你将会得��C��个��用了优质Web架构�Q�这���让你受益）的系�l�。��M���Q�五条关键原则列丑֦�下：

    为所�?#8220;事物”定义ID
    
���所有事物链接在一�?
    
使用标准�Ҏ��
    
资源多重表述
    
无状态通信 

下面让我们进一步审视这些原则�?/p>
为所�?#8220;事物”定义ID 
在这里我使用�?#8220;事物”来代替更正式准确的术�?#8220;资源”�Q�因��Z��条如此简单的原则�Q�不应该被��没在术语当中。思考一下�h们构建的�pȝ���Q�通常会找��C���p�d��值得被标识的关键抽象。每个事物都应该是可标识的，都应该拥有一个明昄���ID——在Web中，代表ID的统一概念是：URI。URI构成了一个全局命名�I�间�Q���用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID�?
对事物��用一致的命名规则�Q�naming scheme�Q�最主要的好处就是你不需要提�������q��规则——而是依靠某个已被定义�Q�在全球范围中几乎完���运行，�q�且能被�l�大多数人所理解的规则。想一下你构徏的上一个应用（假设它不是采用RESTful方式构徏的）中的��L��一个高�U�对象（high-level object�Q�，那就很有可能看到许多从��用唯一标识中受益的用例。比如，如果你的应用中包含一个对��֮�的抽象，那么我可以相当肯定，用户会希望将一个指向某个顾客的链接�Q�能通过电子邮�g发送到同事那里�Q�或者加入到���览器的书签中，甚至写到�U怸�。更透彻地讲�Q�如果在一个类��g��Amazon.com的在�U�商城中�Q�没有用唯一的ID�Q�一个URI�Q�标识它的每一件商品，可想而知�q�将是多么可怕的业务决策�?/p>
当面对这个原则时�Q�许多�h惊讶于这是否意味着需要直接向外界暴露数据库记录（或者数据库记录ID�Q�——自从多�q�以来面向对象的实践告诫我们�Q�要���持久化的信息作为实现细节隐藏�v来之后，哪怕是刚有�Ҏ��法都�怼�使�h惊恐。但是这条原则与隐藏实现�l�节两者之间�ƈ没有��M��冲突�Q�通常�Q�值得被URI标识的事物——资源——要比数据库记录抽象的多。例如，一个定单资源可以由定单��V��地址以及许多其它斚w���Q�可能不希望作�ؓ单独标识的资源暴露出来）�l�成。标识所有值得标识的事物，领会�q�个观念可以�q�一步引��g��创造出在传�l�的应用�E�序设计中不常见的资源：一个流�E�或者流�E�步骤、一�ơ销售、一�ơ谈判、一份报仯���求——这都是应该被标识的事物的示例。同��P���q�也会导致创建比非RESTful设计更多的持久化实体�?
下面是一些你可能惛_��的URI的例子：
http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/4554

http://example.com/processes/salary-increase-234 
正如我选择了创��Z��于阅�ȝ��URI——这是个有用的观点，���管不是RESTful设计所必须的——应该能十分�Ҏ��地推���出URI的含义：它们明显地标识着单一“数据��?#8221;。但是再往下看�Q?/p>
http://example.com/orders/2007/11

http://example.com/products?color=green 
首先�Q�这两个URI看�v来与之前的稍有不同——毕竟，它们不是对一件事物的标识�Q�而是对一�c�M��物集合的标识�Q�假定第一个URI标识了所有在2007�q?1月䆾提交的定单，�W�二个则是绿颜色产品的集合）。但是这些集合自�w�也是事物（资源�Q�，也应该被标识�?/p>
注意�Q���用唯一、全局�l�一的命名规则的好处�Q�既适用于浏览器中的Web应用�Q�也适用于机�Ҏ���Q�machine-to-machine�Q�m2m�Q�通信�?/p>
来对�W�一个原则做下�ȝ���Q���用URI标识所有值得标识的事物，特别是应用中提供的所�?#8220;高��”资源�Q�无�����些资源代表单一数据��V��数据项集合、虚拟亦或实际的对象�q�是计算�l�果�{��?/p>
���所有事物链接在一�?
接下来要讨论的原则有一个有点��o人害怕的正式描述�Q?#8220;���媒体被当作应用状态引擎（Hypermedia as the engine of application state�Q?#8221;�Q�有时简写�ؓHATEOAS。（严格地说�Q�这不是我说的。）�q�个描述的核心是���媒�?/strong>概念�Q�换句话��_���?strong>链接的思想。链接是我们在HTML中常见的概念�Q�但是它的用处绝不局限于此（用于��Z���|�络���览�Q�。考虑一下下面这个虚构的XML片段�Q?
 

 23

 

  

  

 

    

 
如果你观察文档中product和customer的链接，���可以很�Ҏ��地想象到�Q�应用程序（已经���索过文档�Q�如�?#8220;跟随”链接���索更多的信息。当�Ӟ��如果使用一个遵守专用命名规范的����?#8220;id”属性作为链接，
也是可行的—�?strong>但是仅限于应用环境之�?/strong>。��用URI表示链接的优雅之处在于，链接可以指向�׃��同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通�?
���媒体原则还有一个更重要的方面——应�?#8220;状�?#8221;。简而言之，实际上服务器端（如果你愿意，也可以叫服务提供者）为客��L���Q�服务消费者）提供一�l�链接，使客��L��能通过链接���应用从一个状态改变�ؓ另一个状态。稍后我们会在另一���文章中探究�q�个斚w��的媄响；目前�Q�只需要记住：链接是构成动态应用的非常有效的方式�?/p>
�Ҏ��原则�ȝ��如下�Q��Q何可能的情况下，使用链接指引可以被标识的事物�Q�资源）。也正是���链接造就了现在的Web�?/p>
使用标准�Ҏ�� 
在前两个原则的讨��Z��暗含着一个假设：接收URI的应用程序可以通过URI明确�?strong>�?/strong>一些有意义的事情。如果你在公共汽车上看到一个URI�Q�你可以���它输入���览器的地址栏中�q�回车——但是你的浏览器如何知道需要对�q�个URI做些什么呢�Q?/p>
它知道如何去处理URI的原因在于所有的资源都支持同��L��接口�Q�一套同��L���Ҏ���Q�只要你乐意�Q�也可以�U�Cؓ操作�Q�集合。在HTTP中这被叫做动词（verb�Q�，除了两个大家熟知的（GET和POST�Q�之外，标准�Ҏ��集合中还包含PUT、DELETE、HEAD和OPTIONS。这些方法的含义�q�同行�ؓ许诺都一起定义在HTTP规范之中。如果你是一名OO开发�h员，���可以想象到RESTful HTTP�Ҏ��中的所有资源都�l�承自类��g���q�样的一个类�Q�采用类Java、C#的伪语法描述�Q�请注意关键的方法）�Q?/p>
class Resource {

Resource(URI u);

Response get();

Response post(Request r);

Response put(Request r);

Response delete();

} 
�׃��所有资源��用了同样的接口，你可以依此��用GET�Ҏ�����索一�?strong>表述�Q�representation�Q�——也���是对资源的描述。因�����范中定义了GET的语义，所以可以肯定当你调用它的时候不需要对后果负责——这���是��Z��么可�?#8220;安全”地调用此�Ҏ��。GET�Ҏ��支持非常高效、成熟的�~�存�Q�所以在很多情况下，你甚至不需要向服务器发送请求。还可以肯定的是�Q�GET�Ҏ����h���q�等�?/strong>[译注�Q�指多个相同��h���q�回相同的结果]——如果你发送了一个GET��h��没有得到�l�果�Q�你可能不知道原因是��h��未能到达目的圎ͼ��q�是响应在反馈的途中丢失了。幂�{�性保证了你可以简单地再发送一�ơ请求解决问题。幂�{�性同样适用于PUT�Q�基本的含义�?#8220;更新资源数据�Q�如果资源不存在的话�Q�则�Ҏ��此URI创徏一个新的资�?#8221;�Q�和DELETE�Q�你完全可以一遍又一遍地操作它，直到得出�l�论——删除不存在的东西没有�Q何问题）�Ҏ��。POST�Ҏ���Q�通常表示“创徏一个新资源”�Q�也能被用于调用��L���q�程�Q�因而它既不安全也不��h���q�等性�?/p>
如果你采用RESTful的方式暴露应用功能（如果你乐意，也可以称为服务功能）�Q?strong>那这条原则和它的�U�束同样也适用于你。如果你已经习惯于另外的设计方式�Q�则很难��L��受这条原则——毕竟，你很可能认�ؓ你的应用包含了超�����些操作表达范围的逻辑。请允许我花费一些时间来让你�怿�不存在这��L��情况�?
来看下面�q�个���单的采购�Ҏ��例子�Q?

可以看到�Q�例子中定义了两个服务程序（没有包含��M��实现�l�节�Q�。这些服务程序的接口都是��Z��完成��d���Q�正是我们讨论的OrderManagement和CustomerManagement服务�Q�而定制的。如果客��L���E�序试图使用�q�些服务�Q�那它必��针对这些特定接口进行编码——不可能在这些接口定义之前，使用客户�E�序��L��目的地和接口协作。这些接口定义了服务�E�序的应用协议（application protocol�Q��?/p>
在RESTful HTTP方式中，你将通过�l�成HTTP应用协议的通用接口讉K��服务�E�序。你可能会想出像�q�样的方式：

可以看到�Q�服务程序中的特定操作被映射成�ؓ标准的HTTP�Ҏ��——�ؓ了消除歧义，我创��Z��一�l�全新的资源�?#8220;�q�是骗�h的把�?#8221;�Q�我听见你叫��L��。不�Q�这不是�ƺ骗。标识一个顾客的URI上的GET�Ҏ��正好相当于getCustomerDetails操作。有人用三角形�Ş象化地说明了�q�一点：

把三个顶�Ҏ��象�ؓ你可以调节的按钮。可以看到在�W�一�U�方法中�Q�你拥有许多操作�Q�许多种�cȝ��数据以及固定数量�?#8220;实例”�Q�本质上和你拥有的服务程序数量一��_��。在�W�二�U�方法中�Q�你拥有固定数量的操作，许多�U�类的数据和许多调用固定�Ҏ��的对象。它的意义在于，证明了通过�q�两�U�方式，你基本上可以表示��M��你喜�Ƣ的事情�?/p>
��Z��么��用标准方法如此重要？从根本上��_��它��你的应用成�ؓWeb的一部分——应用程序�ؓWeb变成Internet上最成功的应用所做的贡献�Q�与它添加到Web中的资源数量成比例。采用RESTful方式�Q�一个应用可能会向Web中添加数以百万计的客户URI�Q�如果采用CORBA技术�ƈ�l�持应用的原有设计方式，那它的�A献大抵只是一�?#8220;端点�Q�endpoint�Q?#8221;——就好比一个非常小的门�Q�仅仅允许有钥匙的�h�q�入其中的资源域�?/p>
�l�一接口也��得所有理解HTTP应用协议的组件能与你的应用交互。通用客户�E�序�Q�generic client�Q�就是从中受益的�l��g的例子，例如curl、wget、代理、缓存、HTTP服务器、网兌���有Google、Yahoo!、MSN�{�等�?
�ȝ��如下�Q��ؓ使客��L���E�序能与你的资源�怺�协作�Q�资源应该正���地实现默认的应用协议（HTTP�Q�，也就是��用标准的GET、PUT、POST和DELETE�Ҏ���?/p>
资源多重表述 
到目前�ؓ止我们一直忽略了一个稍微复杂的问题�Q�客��L��序如何知道该怎样处理���索到的数据，比如作�ؓGET或者POST��h��的结果？原因是，HTTP采取的方式是允许数据处理和操作调用之间关�p�d����ȝ��。换句话��_��如果客户�E�序知道如何处理一�U�特定的数据格式�Q�那���可以与所有提供这�U�表�q�格式的资源交互。让我们再用一个例子来阐明�q�个观点。利用HTTP内容协商�Q�content negotiation�Q�，客户�E�序可以��h��一�U�特定格式的表述�Q?/p>
GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: application/vnd.mycompany.customer+xml  
��h��的结果可能是一些由公司专有的XML格式表述的客户信息。假讑֮���L��序发送另外一个不同的��h���Q�就如下面这��P��
GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: text/x-vcard 
�l�果则可能是VCard格式的客户地址。（在这里我没有展示响应的内容，在其HTTP Content-type头中应该包含着关于数据�c�d��的元数据。）�q�说明�ؓ什么理想的情况下，资源表述应该采用标准格式——如果客��L��序对HTTP应用协议和一�l�数据格式都有所“了解”�Q�那么它���可以用一�U�有意义的方�?strong>与世界上��L��一个RESTful HTTP应用交互。不�q�的是，我们不可能拿到所有东西的标准格式�Q�但是，或许我们可以惛_��在公司或者一些合作伙伴中使用标准格式来营造一个小环境。当然以上情况不仅适用于从服务器端到客��L��的数据，反之既然——倘若从客��L��传来的数据符合应用协议，那么服务器端���可以��用特定的格式处理数据�Q�而不��d��心客��L��的类型�?
在实践中�Q�资源多重表�q�还有着其它重要的好处：如果你�ؓ你的资源提供HTML和XML两种表述方式�Q�那�q�些资源不仅可以被你的应用所用，�q�可以被��L��标准Web���览器所用——也���是��_��你的应用信息可以被所有会使用Web的�h获取到�?/p>
资源多重表述�q�有另外一�U���用方式：你可以将应用的Web UI�U�_��到Web API中——毕竟，API的设计通常是由UI可以提供的功能驱动的�Q�而UI也是通过API执行动作的。将�q�两个�Q务合二�ؓ一带来了��o人惊讶的好处�Q�这使得使用者和调用�E�序都能得到更好的Web接口�?/p>
�ȝ���Q�针对不同的需求提供资源多重表�q��?/p>
无状态通信
无状态通信是我要讲到的最后一个原则。首先，需要着重强调的是，虽然REST包含无状态性（statelessness�Q�的观念�Q�但�q��ƈ不是说暴露功能的应用不能有状态—�?br />
事实上，在大部分情况下这会导致整个做法没有�Q何用处。REST要求状态要么被攑օ�资源状态中�Q�要么保存在客户端上。或者换句话��_��服务器端不能保持除了单次��h��之外的，��M��与其通信的客��L��的通信状态。这样做的最直接的理由就是可伸羃性—�?如果服务器需要保持客��L��状态，那么大量的客��L��交互会严重媄响服务器的内存可用空��_��footprint�Q�。（注意�Q�要做到无状态通信往往需要需要一些重新设计——不能简单地���一些session状态绑�~�在URI上，然后���宣�U�这个应用是RESTful。）
但除此以外，其它斚w��可能昑־�更�ؓ重要�Q�无状态约束��服务器的变化对客��L��是不可见的，因�ؓ在两�ơ连�l�的��h��中，客户端�ƈ不依赖于同一台服务器。一个客��L��从某台服务器上收��C��份包含链接的文档�Q�当它要做一些处理时�Q�这台服务器宕掉了，可能是硬盘坏掉而被拿去修理�Q�可能是软�g需要升�U�重启——如果这个客��L��讉K��了从�q�台服务器接收的链接�Q�它不会察觉到后台的服务器已�l�改变了�?/p>
理论上的REST
我承认：以上我所说的REST不是真正的REST�Q�而且我可能有点过多地热衷于简单化。但因�ؓ我想有一个与众不同的开场，所以没有在一开始就介绍其正式的定义和背景。现在就让我们稍微简要地介绍一下这斚w��的内宏V�?/p>
首先�Q�先前我�q�没有明���地区分HTTP、RESTful HTTP和REST。要理解�q�些不同斚w��之间的关�p�，我们要先来看看REST的历双Ӏ?/p>
Roy T. Fielding在他�?a id="ewd-" title="博士学位论文" >博士学位论文�Q�实际上你应该访问这个链接——至���对于一���学术论文来��_��它是相当易读的。此论文已被���译�?a id="nev8" title="中文" >中文�Q�中定义了术语REST。Roy曾是许多基本Web协议的主要设计者，其中包括HTTP和URIs�Q��ƈ且他在论文中对这些协议提��Z��很多��x��。（�q�篇论文被誉�?#8220;REST圣经”�Q�这是恰当的——毕竟，是作者发明了�q�个术语�Q�所以在定义上，他写的�Q何内定w��被认为是权威的。）在论文中�Q�Roy首先定义一�U�方法论来谈�?strong>架构风格——高�U�、抽象的模式�Q�来表达架构�Ҏ��背后的核心理��c��每一个架构风格由一�p�d���?strong>�U�束�Q�constraints�Q�定义�Ş成。架构风格的例子包括“没有风格”�Q�根本没有�Q何约束）、管道和�q���o器（pipe and filter�Q�、客��L��/服务器、分布式对象以及——你猜到它了——REST�?/p>
如果对你来说�q�些听�v来都太抽象了�Q�那���对了——REST在本质上是一个可以被许多不同技术实现的高层�ơ的风格�Q�而且可以被实例化——通过为它的抽象特性赋上不同的倹{��比如，REST中包含资源和�l�一接口的概念——也���是��_��所有资源都应该对这些相同的�Ҏ��作出反应。但是REST�q�没有说明是哪些�Ҏ���Q�或者有多少�Ҏ���?/p>
REST风格的一�?#8220;化��n”便是HTTP�Q�以及一套相关的一套标准，比如URI�Q�，或者稍微抽象一些：Web架构自��n。接着上面的例子，HTTP使用HTTP动词作�ؓREST�l�一接口�?#8220;实例”。由于Fielding是在Web已经�Q�或者至���是大部分）“完善”了之后才定义的REST风格�Q�有人可能会争论两者是不是100%的匹配。但是无论如何，整体上来说Web、HTTP和URI仅仅是REST风格的一个主要实现。不�q�，�׃��Roy Fielding��x��REST论文的作者，又对Web架构设计有过��p��的媄响，两者相��g��在情理之中�?/p>
最后，我在前面一�ơ又一�ơ地使用着术语“RESTful HTTP”�Q�原因很���单：许多使用HTTP的应用因��Z��些理由�ƈ没有遵��@REST原则�Q�有��Z��说��用HTTP而不遵��@REST原则���q��同于滥用HTTP。当然这听�v来有点狂热——事实上�q�反REST�U�束的原因通常是，仅仅因�ؓ每个�U�束带来的设计权衡可能不适合于一些特�D�情��c��但通常�Q�违背REST�U�束的原因可归咎于对其好处认知的�~�Z��。来看一个明昄���反面案例�Q���用HTTP GET调用�c�M��于删除对象的操作�Q�这�q�反了REST的安全约束和一般性常识（客户�E�序不应为此负责�Q�服务器端开发�h员大概不是有意而�ؓ之）。但在随后的文章中，我会提及更多�q�样或那��L��对HTTP的滥用�?/p>
�ȝ�� 
本文试图对REST�Q�Web架构�Q�背后的概念提供快速的介绍。RESTful HTTP暴露功能的方式与RPC、分布式对象以及Web Services是不相同的；要真正理解这些不同是需要一些心态的转变。不���你构徏的应用是仅仅��x��露Web UI�q�是��x��API变成Web的一份子�Q�了解下REST的原则还是有好处的�?/p>
Stefan Tilkov是InfoQ SOA�C�֌�的首席编辑，�q�且是位于�d国和瑞士�?/strong>innoQ公司的共同创始�h、首席顾问和REST狂热分子首领�?/strong> 

查看英文原文�Q?a id="mxm5" title="A Brief Introduction to REST" >A Brief Introduction to REST

Eric.Zhou 2008-11-27 16:05 发表评论


关于REST的一�Ҏ��法[转蝲]
Eric.Zhou — Tue, 25 Nov 2008 05:29:00 GMT
�q�阵子正打算用Rails做个东东�Q�所以开始系�l�地学习起了Rails。��y合的是，大概两周前，dlee邀��h��加入Fielding博士关于REST的那���论文的���译团队。可以说Rails和REST�q�两个最热门的词汇几乎同时挤入了我的生活。随着我对Rails的学习和对[Fielding]的翻译，我也开始对REST产生了一些不太成熟的��x���Q�写在这里与大家分��n�Q�同时也起到抛砖引玉的作用，�Ƣ迎大家讨论�?br />


先复习一下REST的基本思想。[Fielding]把REST形式化地定义��Z���U�架构风��|��architecture style�Q�，它有架构元素�Q�element�Q�和架构�U�束�Q�constraint�Q�组成。这些概忉|��较晦涩难懂，而且我们做工�E�的往往�q�不需要�Ş而上的理解。我们只知道�Q�REST是一�U�针对网�l�应用的设计和开发方式，可以降低开发的复杂性，提高�pȝ��的可伸羃性。REST提出了一些设计概念和准则�Q?br />

    �|�络上的所有事物都被抽象�ؓ资源�Q�resource�Q�；
    
每个资源对应一个唯一的资源标识（resource identifier�Q�；
    
通过通用的连接器接口�Q�generic connector interface�Q�对资源�q�行操作�Q?
    
对资源的各种操作不会改变资源标识�Q?
    
所有的操作都是无状态的�Q�stateless�Q��?

对于当今最常见的网�l�应用来��_��resource identifier是url�Q�generic connector interface是HTTP�Q�第4条准则就是我们常说的url不变性。这些概念中的resouce最�Ҏ��使�h产生误解。resouce所指的�q�不是数据，而是数据+特定的表现�Ş式（representation�Q�，�q�也是�ؓ什么REST的全名是Representational State Transfer的原因。�D个例子来��_��“本月卖得最好的10本书”�?#8220;你最喜欢�?0本书”在数据上可能有重叠（有一本书卛_��得好�Q�你又喜�Ƣ）�Q�甚臛_��全相同。但是它们的representation不同�Q�因此是不同的resource�?br />


REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的�Ҏ��限制�?个：index、show、new、edit、create、update和destory�Q�这实际上就是对CURD的实现。更�q�一步讲�Q�Rails�Q�也是当今大部分�|�络应用�Q���用HTTP作�ؓgeneric connector interface�Q�HTTP则把对一个url的操作限制在�?个之内：GET、POST、PUT和DELETE�?br />


REST之所以能够提高系�l�的可�׾~�性，是因为它强制所有操作都是stateless的，�q�样���没有context的约束，如果要做分布式、做集群�Q�就不需要考虑context的问题了。同�Ӟ��它��o�pȝ��可以有效��C��用pool。REST�Ҏ��能的另一个提升来自其对client和server��d��的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这���减���了服务器的开销�?br />


既然REST有这��L��好处�Q�那我们应该义无反顾地拥抱它啊！目前一些大牛（像DHH�Q�都已经开始投入到了REST的世界，那我们这些�h应该做什么或者说思考写什么你呢？我觉得我们应该思考两个问题：


    如何使用REST�Q?
    
REST和MVC的关�p�R�?

�W�一个问题假设REST是我们应该采用的架构�Q�然后讨论如何��用；�W�二个问题则要说明REST和当前最普遍应用的MVC是什么关�p�，互补�q�是取代�Q?br />


我们先来谈谈�W�一个问题，如何使用REST。我感觉�Q�REST除了�l�我们带来了一个崭新的架构以外�Q�还有一个重要的贡献是在开发系�l�过�E�中的一�U�新的思维方式�Q�通过url来设计系�l�的�l�构。根据REST�Q�每个url都代表一个resource�Q�而整个系�l�就是由�q�些resource�l�成的。因此，如果url是设计良好的�Q�那么系�l�的�l�构��׃��应该是设计良好的。对于非高手�U�的开发�h员来��_��考虑一个系�l�如何架构��L��一个很抽象的问题。敏捷开发所提倡的Test Driven Development�Q�其好处之一�Q�我觉得是最大的好处�Q�就是可以通过testcase直观地设计系�l�的接口。比如在�q�没有创��Z��个class的时候就�~�写一个testcase�Q�虽然设�|�不能通过�~�译�Q�但是testcase中的�Ҏ��调用可以很好��C��class使用者的角度反映出需要的接口�Q�从而�ؓclass的设计提供了直观的表现。这与在REST架构中通过url设计�pȝ���l�构非常�c�M��。虽然我们连一个功能都没有实现�Q�但是我们可以先设计出我们认为合理的url�Q�这些url甚至不能�q�接��C�Q何page或action�Q�但是它们直观地告诉我们�Q�系�l�对用户的访问接口就应该是这栗���根据这些url�Q�我们可以很方便地设计系�l�的�l�构�?br />


让我在这里重申一遍：REST允许我们通过url设计�pȝ���Q�就像Test Driven Development允许我们使用testcase设计class接口一栗��?br />


OK�Q�既然url有这��L��好处�Q�那我们���q��重讨��Z��下如何设计url。网�l�应用通常都是有hierarchy的，像棵大树。我们通常希望url也能反映�����源的层次性。比如对于一个blog应用�Q?articles表示所有的文章�Q?articles/1表示id�?的文章，�q�都比较直观。遗憄���是，�|�络应用的资源结构永�q�不会如此简单。因此�h们常�怼�问这样一个问题：RESTful的url能覆盖所有的用户��h��吗？比如�Q�login如何RESTful�Q�search如何RESTful�Q?br />


从REST的概念上来看�Q�所有可以被抽象�����源的东东都可以��用RESTful的url。因此对于上面的两个问题�Q�如果login和search可以被抽象�ؓ资源�Q�那么就可以使用RESTful的url。search比较���单，因�ؓ它会�q�回搜烦�l�果�Q�因此可以被抽象�����源，�q�且只实现index�Ҏ�����可以了�Q�只需要显�C�搜索结果，没有create、destory之类的东西）。然而这里面也有一个问题：search的关键字如何传给server�Q�index�Ҏ��昄���应该使用HTTP GET�Q�这会把关键字加到url后面�Q�当然不�W�合REST的风根{��要解决�q�个问题�Q�可以把每次search看作一个资源，因此要创建create和index�Ҏ���Q�create用来在用��L���?#8220;搜烦”按钮是通过HTTP POST把关键字传给server�Q�然后index则用来显�C�搜索结果。这样一来，我们�q�可以记录用��L��搜烦历史。��用同��L���Ҏ���Q�我们也可以对login应用REST�Q�即每次login动作是一个资源�?br />


现在�Q�我们来复杂一些的东东。如何用url表达“category为ruby的article”�Q�一开始可能想到的�?category/ruby/articles�Q�这�U�想法很直观。但是我觉得里面的category是不需要的�Q�我们可以直接把“/ruby”理解�?#8220;category是ruby”�Q�也���是�?#8220;ruby”出现的位�|�说明了它指的就是category。OK�Q?ruby/articles�Q�单单从�q�个url上看�Q�我们能获得多少关于category的信息呢�Q�显然category隐藏在了url后面�Q�这样做到底好不好，应该是仁者见仁，�����见��Z��。对于如何表达category�q�样的东西，我还没想出很好的方式�Q�大家有什么好idea�Q�可以一赯���论�?br />


另外�q�有一�U�url形式�Q�它对应到程序中的��承关�p�R��比如product是一个父�c�，book和computer是其子类。那么所有��品的url应该�?products�Q�所有书�c�的url应该�?books�Q�所有电脑的url应该�?computers。这一��x�����比较直观了�Q�而且再次验证了url可以帮助我们�q�行设计的论炏V�?br />


让我再说明一下我的想法：如果每个用户需求都可以抽象�����源，那么���可以完全��用REST�?/strong>



由此看来�Q���用REST的关键是如何抽象资源�Q�抽象得���精���，对REST的应用就���好。因此，如何改变我们目前�Ҏ��蒂固的基于action的思想是最重要的�?br />


有了对第一个问题的讨论�Q�第二个问题���容易讨论多了。REST会取代MVC吗？�q�是彼此是互补关�p�（���像AOP对于OOP�Q�？�{�案是It depends�Q�如果我们可以把所有的用户需求都可以抽象�����源，那么MVC���可以退出历史的舞台了。如果情�늛�反，那么我们���需要�؜合��用REST和MVC�?br />


当然�Q�这是非常理想的论断。可能我们无法找��C���U�方法可以把所有的用户需求都抽象�����源，因�ؓ保证�q�种抽象的完整性（即真的是所有需求都可以�Q�需要�Ş式化的证明。而且即��被证明出来了�Q�由于开发�h员的能力和喜好不同，MVC肯定也会成�ؓ不少人的首选。但是对于希望拥抱REST的�h来说�Q�这些都没有关系。只要你开发的�pȝ��所设计的问题域可以被合理地抽象�����源，那么REST��׃��成�ؓ你的开发利器�?br />


所以，所有希望拥抱REST的朋友们�Q�赶快训�l�自己如何带上资源的眼镜看世界吧�Q�这才是REST的核心所在�?/strong> 

转蝲自javaeye论坛　作者：AllenYoung
原文地址�Q?a >http://www.javaeye.com/topic/70113


Eric.Zhou 2008-11-25 13:29 发表评论

97久久超碰,久久精品亚洲一区二区三区浴池 ,久草视频视频在线播放

REST in Spring 3: @MVC

A Bit of Background

RESTful features in Spring MVC 3.0

URI Templates

Content Negotiation

Views

HTTP Method Conversion

ETag support

And more!

Similar Posts

Spring MVC Annotation & Convention Over Configuration

深入���出REST[转蝲]

REST关键原则

为所�?#8220;事物”定义ID

���所有事物链接在一�?

使用标准�Ҏ��

资源多重表述

无状态通信

理论上的REST

�ȝ��

关于REST的一�Ҏ��法[转蝲]

深入��出REST[转蝲]

��所有事物链接在一�?