使用Spring MVC构建REST风格WEB应用

转载地址：http://www.360doc.com/content/12/0925/10/7471983_238046800.shtml

对于运行在网络上的MIS系统而言，处理数据的是整个系统的主要任务，翻开程序我们可以看到，80%以上的代码都在处理数据的CRUD操作。采用一种什么样的框架结构，能够使得处理数据的操作变得简单且易理解，这是大部分开发者尤其是架构设计者一直以来思考的一个问题。

REST(Representational State Transfer)是一种编程风格，特别是针对网络应用的设计和开发，采用REST可以显著降低开发的复杂性，提高系统的可伸缩性。

REST是一种独特的编程风格，与MVC强调的角色分层概念不同，REST强调使用统一的规则来规范对资源的操作，两者互为补充，相符相成，使用 MVC架构搭配REST编程风格构建基于网络的MIS系统将在不远的为未成为主流。本文着重介绍REST编程风格的核心规则，并且结合Spring MVC描述REST在实际应用中的代码形态。

（本文系作者原创，请尊重作者的权利。本文欢迎转载，如转载必须注明作者及出处！)

使用REST风格开发WEB应用程序强调以下几点规则：

1. 网络上的所有事物都被抽象为资源（resource）；
2. 每个资源对应一个唯一的资源标识（resource identifier）；
3. 通过通用的连接器接口（generic connector interface）对资源进行操作；
4. 对资源的各种操作不会改变资源标识；
5. 所有的操作都是无状态的（stateless）。

首先，在笔者看来，REST定义中的资源就即应用程序所处理的数据。以订单管理系统为例，订单信息就是数据，同样客户信息和产品信息也是数据，在REST看来这些数据都是资源。

REST强调资源必须有具有唯一名称和ID，名称用来区分不同资源，ID用来定位同类资源中唯一的一条数据。在REST中，这些规则都是通过URI 来描述的。还是以上面的订单系统为例，我们将订单信息名称设定为order，客户信息为customer，货物信息为product，那么就存在几下的几 种URI设计：

1 2 3 4 5 6 7 8

<!--标识所有的订单信息--> http://www.coolfancy.com/rest/order   <!--标识所有的客户信息--> http://www.coolfancy.com/rest/customer   <!--标识ID为1的货物信息--> http://www.coolfancy.com/rest/product/1

我们可以看出REST风格URI设计的特点：http://host/context/资源名称/[资源ID]。其中资源名称是必选项，资源ID可省略，省略资源ID用来标识一类资源的所有数据。

有了资源和用来标识资源的URI后，REST用连接器来标识对资源的操作。在这里，对资源的操作分为查询/获取、创建、删除、修改四种。在网络编程环境下，REST用HTTP协议作为连接器，用HTTP Method（请求方法）标识操作类型：

• HTTP GET:查询和获取资源；
• HTTP POST:创建资源；
• HTTP PUT: 修改资源；
• HTTP DELETE: 删除资源。

在完成资源和连接器两个核心概念的定义后，我们已经可以大体勾勒出REST风格编程的基本思路：

1. 抽象和定义系统中的资源；
2. 使用REST风格的URI将请求与资源进行绑定；
3. 使用HTTP请求对资源进行操作；

还用上面提到的订单系统为例，请看下面的例子：

1 2 3 4 5

<!--查询类别为服装的货物信息--> GET /rest/product HTTP/1.1 Host: www.coolfancy.com   productType 服装

1 2 3

<!--查询ID为1的订单信息--> GET /rest/order/1 HTTP/1.1 Host: www.coolfancy.com

1 2 3

<!--删除ID为1的货物信息--> DELET /rest/product/1 HTTP/1.1 Host: www.coolfancy.com

1 2 3 4 5 6 7

<!--创建一条订单信息--> POST /rest/order HTTP/1.1 Host: www.coolfancy.com   field1 value1 field2 value2 ... ...

简单的说，URI加上HTTP METHOD构成了REST处理数据的核心规则：URI确定了操作的对象，HTTP METHOD则确定了操作的方式。

与传统处理数据的方式不同，如果不使用REST，那么操作的对象和操作方式将混合在URL设计中，正如首次提出REST概念的Roy T. Fielding博士所说的：“REST允许我们通过url设计系统”。事实上Roy也是Web协议的主要设计者，正是在他的参与下完成了HTTP1.1 规范的制定。

站在另一个角度，REST强调资源（数据）的概念，一切操作围绕特定资源展开，离开了资源，REST就失去了存在的意义。在这一点上，REST所倡导的思想与时下流行的Ajax的编程风格有着异曲同工之妙。

Ajax强调数据与展现分离，后台应用程序致力于生产数据，前台使用脚本进行数据的展示。对于数据的组织与传输Ajax并没有内置的支持。而 REST强调通过URI将请求与资源进行绑定，如果将REST与Ajax技术进行结合，则可以形成有效的互补，我们不妨将上面提到的编程思路进行扩展，仍 然以获取ID为1的订单信息为例：

1. Ajax发起请求:http://www.coolfancy.com/rest/order/1；
2. 通过REST风格的URI设计将请求与后台实体进行绑定；
3. 后台实体返回包含产品信息的JSON/XML数据；
4. 前台使用脚本进行数据的展示。

我们用Spring MVC来实现上面描述的过程，作为主流的MVC产品，Spring MVC天然支持REST编程风格，所以使用Spring MVC来搭建REST风格的应用程序将变得异常简单。

Spring MVC使用特殊的标注对Handler对象进行修饰，使得Handler能够处理REST风格的请求，我们来看几个例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

/**   * 按ID值获取订单信息   *   * @param id   * @return   */ @ResponseBody @RequestMapping (value =  "/order/${id}" , method = RequestMethod.GET) public  OrderEntity getOrder( @PathVariable  int  id) {      return  orderManager.get(id); }   /**   * 按类型查询货物信息   *   * @param id   * @return   */ @ResponseBody @RequestMapping (value =  "/product" , method = RequestMethod.GET) public  List<ProductEntity> getProductByType(String type) {      return  productManager.queryByType(type); }   /**   * 创建订单信息   *   * @param id   * @return   */ @RequestMapping (value =  "/order" , method = RequestMethod.POST) public  void  createOrder(OrderEntity entity) {      orderManager.create(entity); }   /**   * 修改订单信息   *   * @param id   * @return   */ @RequestMapping (value =  "/order/${id}" , method = RequestMethod.PUT) public  OrderEntity updateOrder( @PathVariable  int  id, OrderEntity entity) {      return  orderManager.update(entity); }   /**   * 删除指定ID值的订单信息   *   * @param id   * @return   */ @RequestMapping (value =  "/order/${id}" , method = RequestMethod.DELETE) public  void  deleteOrder( @PathVariable  int  id) {      orderManager.delete(id); }

通过上面的例子可以看出，使用Spring MVC编写REST风格的应用程序是多么的简单。

需要我们注意的是，REST要求资源的标识是不变的，也就是说对于特定的资源，无论对这个资源作了什么样的操作，资源的ID不可以改变。之所以加入 这样的限制是为了保证URI的一致性。试想如果某个操作在处理过程中改变了资源的标识，那么为了保证规则的完整性，我们必须付出额外的代价去在其它的处理 中同步这些变化，这在REST中是不可接受的。

另一方面，REST要求针对资源的所有操作必须是无状态的，URI是确定资源的唯一途径。如果我们在处理数据的过程中融入了状态数据，那么针对同一资源的URI就会出现二义性，这将与REST的定义背道而驰。