RESTful介绍

什么是REST？
　REST (REpresentational State Transfer) 描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy

Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。
　REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
　Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包

含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务

器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
　在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对

象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一

的界面，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用

程序状态的引擎，资源表示通过超链接互联。
　另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以

限制整个系统的复杂性，促进了底层的独立性。
　当 REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的

交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。

RESTful的实现：RESTful Web 服务与 RPC 样式的 Web 服务
　了解了什么是REST，我们再看看RESTful的实现。最近，使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的

扫描二维码关注公众号，回复： 647887 查看本文章

方法。RPC 样式的 Web 服务客户端将一个装满数据的信封（包括方法和参数信息）通过 HTTP 发送到服务器。服务器打开信封并使

用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独

特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务，URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。
　由于轻量级以及通过 HTTP 直接传输数据的特性，Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言（比

如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax]）实现客户端。RESTful Web 服务通常可以通过自动客户端或

代表用户的应用程序访问。但是，这种服务的简便性让用户能够与之直接交互，使用它们的 Web 浏览器构建一个 GET URL 并读取返

回的内容。
　在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方

法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。
　在 RPC 样式的架构中，关注点在于方法，而在 REST 样式的架构中，关注点在于资源 —— 将使用标准方法检索并操作信息片段

（使用表示的形式）。资源表示形式在表示形式中使用超链接互联。
　Leonard Richardson 和 Sam Ruby 在他们的著作 RESTful Web Services 中引入了术语 REST-RPC 混合架构。REST-RPC 混合 Web

服务不使用信封包装方法、参数和数据，而是直接通过 HTTP 传输数据，这与 REST 样式的 Web 服务是类似的。但是它不使用标准

的 HTTP 方法操作资源。它在 HTTP 请求的 URI 部分存储方法信息。好几个知名的 Web 服务，比如 Yahoo 的 Flickr API 和 del

icio us API 都使用这种混合架构。

RESTful的实现：RESTful Web 服务的 Java 框架
　有两个 Java 框架可以帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet（见参考资料）是轻量级的

。它实现针对各种 RESTful 系统的资源、表示、连接器和媒体类型之类的概念，包括 Web 服务。在 Restlet 框架中，客户端和服

务器都是组件。组件通过连接器互相通信。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet，该类的子类是专用类，

比如 Application、Filter、Finder、Router 和 Route。这些子类能够一起处理验证、过滤、安全、数据转换以及将传入请求路由

到相应资源等操作。Resource 类生成客户端的表示形式。
　JSR-311是 Sun Microsystems 的规范，可以为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。
　JSR-311 提供一组注释，相关类和接口都可以用来将 Java 对象作为 Web 资源展示。该规范假定 HTTP 是底层网络协议。它使用

注释提供 URI 和相应资源类之间的清晰映射，以及 HTTP 方法与 Java 对象方法之间的映射。API 支持广泛的 HTTP 实体内容类型

，包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能，以允许使用标准方法通过应用程序添加其他类型。

RESTful的实现：构建 RESTful Web 服务的多层架构
　RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数，尽管客户端的种类

不同。例如，在线电子商务分类网站为用户提供一个浏览器界面，用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售

商甚至个人能够自动订购产品，它将非常有用。与大部分动态 Web 应用程序一样，Web 服务可以从多层架构的关注点分离中受益。

业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外，从数据访问中分

离业务逻辑可实现数据库独立性，并为各种类型的数据存储提供插件能力。
　图 1 展示了自动化客户端，包括 Java 和各种语言编写的脚本，这些语言包括 Python、Perl、Ruby、PHP 或命令行工具，比如

curl。在浏览器中运行且作为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列，因为它们都

代表用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请

求在头部包含方法信息，即 POST、GET、PUT 和 DELETE，这又将映射到 Resource Request Handler 中资源的相应操作。每个请求

都包含所有必需的信息，包括 Resource Request Handler 用来处理请求的凭据。
　从 Web 服务客户端收到请求之后，Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 确定所有概

念性的实体，系统将这些实体作为资源公开，并为每个资源分配一个惟一的 URI。但是，概念性的实体在该层是不存在的。它们存在

于业务逻辑层。可以使用 Jersey 或其他框架（比如 Restlet）实现 Resource Request Handler，它应该是轻量级的，将大量职责

工作委托给业务层。
　Ajax 和 RESTful Web 服务本质上是互为补充的。它们都可以利用大量 Web 技术和标准，比如 HTML、JavaScript、浏览器对象、

XML/JSON 和 HTTP。当然也不需要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web

服务为 Ajax 提供了非常简单的 API 来处理服务器上资源之间的交互。
　图 1 中的 Web 浏览器客户端作为 GUI 的前端，使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。

Browser Requester Handler 可以使用 MVC 模型（JSF、Struts 或 Spring 都是 Java 的例子）。它从浏览器接受请求，从业务逻

辑层请求服务，生成表示并对浏览器做出响应。表示供用户在浏览器中显示使用。表示不仅包含内容，还包含显示的属性，比如

HTML 和 CSS。
　业务规则可以集中到业务逻辑层，该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表

示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用，并能实现灵活和可扩

展的架构。此外，由于将来可以使用新的 REST 和 MVC 框架，实现它们变得更加容易，无需重写业务逻辑层。
　数据访问层提供与数据存储层的交互，可以使用 DAO 设计模式或者对象-关系映射解决方案（如 Hibernate、OJB 或 iBATIS）实

现。作为替代方案，业务层和数据访问层中的组件可以实现为 EJB 组件，并取得 EJB 容器的支持，该容器可以为组件生命周期提供

便利，管理持久性、事务和资源配置。但是，这需要一个遵从 Java EE 的应用服务器（比如 JBoss），并且可能无法处理 Tomcat。

该层的作用在于针对不同的数据存储技术，从业务逻辑中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点，可以成

为其他 Web 服务的客户端。
　数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统（包括遗留系统、事务处理系统和企业资源规划系统）。使

用该架构，您可以开始看到 RESTful Web 服务的力量，它可以灵活地成为任何企业数据存储的统一 API，从而向以用户为中心的

Web 应用程序公开垂直数据，并自动化批量报告脚本。

什么是REST：结束语
　REST 描述了一个架构样式的互联系统（如 Web 应用程序）。REST 约束条件作为一个整体应用时，将生成一个简单、可扩展、有

效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性，RESTful Web 服务成为基于 SOAP 服务的一个最

有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分

离。Ajax 和 RESTful Web 服务本质上是互为补充的。开发人员可以轻松使用 Ajax 和 RESTful Web 服务一起创建丰富的界面。

目前宣称支持REST的Java框架包括以下这些：
Restlet（http://www.restlet.org/）
Cetia4（https://cetia4.dev.java.net/）
Apache Axis2（http://http://ws.apache.org/axis2/）
sqlREST（http://sqlrest.sourceforge.net/）
REST-art（http://rest-art.sourceforge.net/）

以下对这些框架进行了较为全面的分析。

Restlet，最新版本1.0.1
特点：完全抛弃了Servlet API，作为替代，自己实现了一套API。能够支持复杂的REST架构设计。
缺点：
1. 虽然也可以运行于Web容器中，但是难以利用Servlet和JSP等资源。因为需要另外学习一套API和概念，学习成本比较高。
2. 完全不支持服务器端的HTTP Session，强制完全基于无状态服务器模型来做开发。对于基于浏览器的应用来说，开发难度较高。
3. 自身没有包括与Spring的集成，可以使用第三方代码与Spring集成，集成难度较大。
4. 文档不是很丰富，大多比较简短，很多时候需要自己去读代码，或者到其wiki上去查找。
5. 没有内建的国际化支持。
优点：
1. 有内建的HTTP认证机制，不需要另外开发安全机制。
2. 灵活性较高，支持更多的REST概念，支持透明的内容协商，适合于开发更加强大的REST组件（不限于服务器端应用）。
3. 零配置文件，全部配置通过代码来完成。

发。
3. 自身包括了对于Web MVC的支持，熟悉Web MVC框架的开发者很容易理解。还内建了参数映射、参数验证等等传统Web MVC框架所支

持的功能。
4. 内建了自己特有的导航对象栈的概念，对于支持传统的Web应用的开发（基于浏览器的导航）非常有帮助。
5. 提供了JSP标签库，对于传统的基于HTML表单的Web开发非常有帮助。
6. 支持与SiteMesh相配合，由SiteMesh来支持页面布局的重用。
7. 内建有与Spring的集成，集成起来非常容易。
8. 配置文件完全基于标准的web.xml，不需要额外的配置文件。大量使用默认配置，一般情况下足以满足常见的需求。
9. 拥有很好的文档。
10. 有内建的国际化支持。
缺点：
1. 没有内建的HTTP认证机制，需要自行开发安全机制。
2. 对于内容协商的支持比较弱，仅支持HTML和XML格式的表现。需要加以扩展才能支持其他格式的表现。

Axis2，最新版本1.2
特点：同时支持SOAP和REST风格的Web Service。
缺点：
1. 仅仅支持GET与POST方法。
2. 仅仅是以REST风格暴露出Web服务，数据格式仍然是包含SOAP封装的XML，不能使用更加有效的格式。
3. 只支持同步的调用方式。
4. 仅仅提供了以SOAP方式暴露Web服务的最小化的支持，不支持全面的REST架构设计。

相关资源：
简介：http://ws.apache.org/axis2/1_2/rest-ws.html

sqlREST，最新版本0.3.1
特点：
1. 为任何可以通过JDBC访问的数据库提供Web服务访问接口，自动将REST风格的HTTP请求转换为相应的数据库SQL语句，并将数据库

中的记录编码为XML格式传给客户端。是REST风格的HTTP请求到数据库中的数据的直接映射。
2. 基于Servlet API开发。
缺点：
1. 因为是REST风格的HTTP请求到SQL语句的直接映射，因此强制使用以SQL和关系数据库为中心的数据建模设计方法，不支持面向对

象的设计。灵活性很低，难以实现较为复杂的业务逻辑。
2. 因为资源的定义仅限于数据库的表，难以实现更高层次的抽象，必然会导致非常细粒度的API。应用的性能和可伸缩性都难以保证

。

相关资源：
教程：http://sqlrest.sourceforge.net/5-minutes-guide.htm

REST-art，最新版本0.2
特点：一个旨在替换复杂的SOAP框架的REST框架，用来作为替代SOAP方便地发布Web服务的工具。不是基于Servlet API开发。
缺点：
1. 目前尚处于刚刚起步的阶段，功能非常少。
2. 不是基于Servlet API，带来了额外的学习成本。

相关资源：
教程：http://sourceforge.net/docman/index.php?group_id=175132

REST的主要优势在我看来其实在于它是一种对于服务器的更加有效的抽象方式。

对于基于网络的应用来说，你怎么样看待服务器，就会产生什么样的架构风格，随之产生与该架构风格相关的交互模式。

RPC架构风格将服务器看作是由一些过程组成，客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性

的（做某件事），因此RPC建模是以动词为中心的。

分布式对象架构风格认为服务器是由一些对象和对象上的方法组成，客户端通过调用这些对象上的方法来执行特定的任务。并且客户

端调用这些对象上的方法应该就像是调用本地对象上的方法一样，这样开发就可以完全按照统一的面向对象方法来做。但是很可惜，

这样的抽象并不是很有效，因为分布式对象与本地对象存在着巨大的本质差别，想要掩盖这些差别很多时候甚至是有害无益的。

REST架构风格并没有试图掩盖这些差别，而是将服务器抽象为一组离散资源的集合。资源是一个抽象的概念，而不是代表某个具体的

东西。注意：要真正理解REST，就一定要增强自己的抽象思维能力，充分理解到资源是抽象的。如果完全不具有抽象思维的能力，一

定要将资源与数据库中的一张表或服务器端的一个文件（HTML、Servlet、JSP、etc.）一一挂起钩来，就无法真正理解REST了。资源

是名词性的，因此REST建模是以名词为中心的。

上述是目前基于网络的应用的主要的三种抽象方式。这三种不同的抽象方式会严重影响客户端与服务器的交互模式，而不同交互模式

的交互效率差别相当大。分布式对象的交互模式很多时候效率很低，因为掩盖了分布式对象与本地对象的差别，很多时候都会导致细

粒度的API（需要一再强调才能让一些不明就里的架构初哥按照正确的方式来做设计）。实践已经证明，与RPC和分布式对象相比，

REST是一种对于服务器更加有效的抽象方式，将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻

合的，REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性

，而是互操作性。除非出现奇迹，否则你种什么，就应该长出来什么。你种的是瓜，长出来的就是瓜；你种的是豆，长出来的就是豆

。

REST 在 2000 年由 Roy Fielding 在博士论文中提出，他是 HTTP 规范 1.0 和 1.1 版的首席作者之一。
REST 中最重要的概念是资源（resources），使用全球 ID（通常使用 URI）标识。客户端应用程序使用 HTTP 方法（GET/ POST/

PUT/ DELETE）操作资源或资源集。RESTful Web 服务是使用 HTTP 和 REST 原理实现的 Web 服务。通常，RESTful Web 服务应该定

义以下方面：
•Web 服务的基/根 URI，比如 http://host/<appcontext>/resources。
•支持 MIME 类型的响应数据，包括 JSON/XML/ATOM 等等。•服务支持的操作集合（例如 POST、GET、PUT 或 DELETE）。

Jersey（https://jersey.dev.java.net/）

Apache CXF（http://cxf.apache.org/）

Sping3(http://www.springsource.org/)

以下对这些框架进行了较为全面的分析。

Restlet，最新版本2.1
特点：完全抛弃了Servlet API，作为替代，自己实现了一套API。能够支持复杂的REST架构设计。
缺点：
1. 虽然也可以运行于Web容器中，但是难以利用Servlet和JSP等资源。因为需要另外学习一套API和概念，学习成本比较高。
2. 完全不支持服务器端的HTTP Session，强制完全基于无状态服务器模型来做开发。对于基于浏览器的应用来说，开发难度较高。
3. 自身没有包括与Spring的集成，可以使用第三方代码与Spring集成，集成难度较大。
4. 文档不是很丰富，大多比较简短，很多时候需要自己去读代码，或者到其wiki上去查找。
5. 没有内建的国际化支持。
优点：
1. 有内建的HTTP认证机制，不需要另外开发安全机制。
2. 灵活性较高，支持更多的REST概念，支持透明的内容协商，适合于开发更加强大的REST组件（不限于服务器端应用）。
3. 零配置文件，全部配置通过代码来完成。

Cetia4，最新版本1.0
特点：基于Servlet API开发，可以运行于所有的Web容器中。
优点：
1. 可以充分利用Servlet API和JSP等资源，需要额外学习的概念较少，学习成本较低。
2. 对于传统的Web应用，可以使用服务器端HTTP Session；对于Web服务类应用，不使用HTTP Session，基于无状态服务器模型做开发。
3. 自身包括了对于Web MVC的支持，熟悉Web MVC框架的开发者很容易理解。还内建了参数映射、参数验证等等传统Web MVC框架所支持的功能。
4. 内建了自己特有的导航对象栈的概念，对于支持传统的Web应用的开发（基于浏览器的导航）非常有帮助。
5. 提供了JSP标签库，对于传统的基于HTML表单的Web开发非常有帮助。
6. 支持与SiteMesh相配合，由SiteMesh来支持页面布局的重用。
7. 内建有与Spring的集成，集成起来非常容易。
8. 配置文件完全基于标准的web.xml，不需要额外的配置文件。大量使用默认配置，一般情况下足以满足常见的需求。
9. 拥有很好的文档。
10. 有内建的国际化支持。
缺点：
1. 没有内建的HTTP认证机制，需要自行开发安全机制。
2. 对于内容协商的支持比较弱，仅支持HTML和XML格式的表现。需要加以扩展才能支持其他格式的表现。

Axis2，最新版本1.5.4
特点：同时支持SOAP和REST风格的Web Service。
缺点：
1. 仅仅支持GET与POST方法。
2. 仅仅是以REST风格暴露出Web服务，数据格式仍然是包含SOAP封装的XML，不能使用更加有效的格式。
3. 只支持同步的调用方式。
4. 仅仅提供了以SOAP方式暴露Web服务的最小化的支持，不支持全面的REST架构设计。

相关资源：
简介：http://ws.apache.org/axis2/1_2/rest-ws.html

sqlREST，最新版本0.3.1
特点：
1. 为任何可以通过JDBC访问的数据库提供Web服务访问接口，自动将REST风格的HTTP请求转换为相应的数据库SQL语句，并将数据库中的记录编码为XML格式传给客户端。是REST风格的HTTP请求到数据库中的数据的直接映射。
2. 基于Servlet API开发。
缺点：
1. 因为是REST风格的HTTP请求到SQL语句的直接映射，因此强制使用以SQL和关系数据库为中心的数据建模设计方法，不支持面向对象的设计。灵活性很低，难以实现较为复杂的业务逻辑。
2. 因为资源的定义仅限于数据库的表，难以实现更高层次的抽象，必然会导致非常细粒度的API。应用的性能和可伸缩性都难以保证。

相关资源：
教程：http://sqlrest.sourceforge.net/5-minutes-guide.htm

Sun正在致力于的建立RESt风格Web服务的规范，规范如下
JSRs: Java Specification Requests
JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

Jersey 是JAX-RS的参考实现，现在已经是1.8版，然而并不是最终版本，因为JAX-RS还没有到最终版本。但是现在的Jersey已经足以让Java爱好者一饱coding福了。

首先，Jersey采用了Annotation机制，所有的HTTP相关的参数设置都采用标注实现，因此，在编程的时候，我们好像针对的仍然是POJO，体会不到分布式或J2EE编程的痛苦，只要了解一些关键Annotation的用户即可。

其次，Jersey是一个开发的平台，我们可以扩展自己的需求，比如在消息格式上，虽然Jersey已经提供了Java基本数据类型、JSON、XML等类型，我们还是可以很容易的扩展自己的格式。

第三，Jersey建立的服务可以很简单的部署到JDK6自带的轻量级Server上，过程极其简单。

第四，Jersey建立的服务可以非常容易的部署为Servlet，支持各种J2EE容器。

第五，Jersey可以为我们编写的服务自动生成WADL

第六，支持Spring.

（参见http://jersey.java.net/nonav/documentation/latest/chapter_deps.html）

Apache CXF 则是由 Celtix 和 XFire 项目整合而生，目前最新版本2.4.1，不过仍是 Apache 的一个孵化项目。

CXF 包含了大量的功能特性，但是主要集中在以下几个方面：

1.支持 Web Services 标准：CXF 支持多种 Web Services 标准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。
2.Frontends：CXF 支持多种“Frontend”编程模型，CXF 实现了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一个“simple frontend”允许客户端和 EndPoint 的创建，而不需要 Annotation 注解。CXF 既支持 WSDL 优先开发，也支持从 Java 的代码优先开发模式。
3.容易使用： CXF 设计得更加直观与容易使用。有大量简单的 API 用来快速地构建代码优先的 Services，各种 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加简化的 XML 配置方式，等等。
4.支持二进制和遗留协议：CXF 的设计是一种可插拨的架构，既可以支持 XML ，也可以支持非 XML 的类型绑定，比如：JSON 和 CORBA。

一、与Axis2的不同之处
1、Apache CXF 支持 WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-I BasicProfile
2、Axis2 支持 WS-Addressing、WS-RM、WS-Security和WS-I BasicProfile，WS-Policy将在新版本里得到支持
3、Apache CXF 是根据Spring哲学来进行编写的，即可以无缝地与Spring进行整合
4、Axis2 不是
5、Axis2 支持更多的 data bindings，包括 XMLBeans、JiBX、JaxMe 和 JaxBRI，以及它原生的 data binding（ADB）。
6、Apache CXF 目前仅支持 JAXB 和 Aegis，并且默认是 JAXB 2.0，与 XFire 默认是支持 Aegis 不同，XMLBeans、JiBX 和 Castor 将在 CXF 2.1 版本中得到支持，目前版本是 2.0.2
7、Axis2 支持多种语言，它有 C/C++ 版本。
8、Apache CXF 提供方便的Spring整合方法，可以通过注解、Spring标签式配置来暴露Web Services和消费Web Services

Spring3新增的特性

1、迁移到Java5

由于完全基于Java5构建了，应该很多接口增加了泛型的支持，如getBean()后可以不用再转型了，任务执行器继承了Java5的Executor。

2、新增Spring表达式语言，简称SpEL

Spring终于支持了在配置文件中使用表达式语言，而不再是简单的属性文件变量，这应该是一个不错的特性。不只是配置文件，注解里也支持EL。

3、支持以Java代码+注解方式来配置元数据

曾记得在07年的时候，发现Spring推出一个有意思的子项目JavaConfig，它不使用XML，而是采用Java的类和方法，来定义容器和Bean，感觉很新颖。不过当时想来，用代码来配置，虽然能获得强类型检查的好处，防止配置输入错误，但是也失去了最大的好处：直接修改的灵活性。

隔两年，Spring才在核心包里加入了这个特性，或许就是因为这个缺点。而之所以在3.0里加进来，最大的原因或许是由于SpEL，既然能够在注解里使用EL，那么灵活性就大大提高了，只要合理规划元数据结构，应该可以获得强类型配置 + 灵活性变更的双重好处。Spring3发布后，JavaConfig + SpEL或许会成为一种较好的元数据定义方式。

4、对象到XML的映射

又是一个从子项目移入核心包的特性，对象XML隐射(OXM)，来自WebServices子项目，提供JAXB、XmlBeans以及XStream等方式的实现。

5、全面的REST支持

包括服务端和客户端，提供了RestTemplate支持全功能的REST客户端，基于HttpClient。

6、注解声明式验证框架

支持自动发现HibernateValidator的jar，设置为对JSR303注解验证框架的实现。

项目由于本身是Strus2+Sprng2.4+Ibatis2的,用spirng3基本排除了，目前优先考虑使用Jersey 、CXF。

猜你喜欢