Restlet 1.1.0：改进的灵活性和规范支持

Restlet是一个用来构建REST-ful应用的Java框架，它在上周发布了1.1.0版（该版本是自2007年4月以来第一个主要的发布），这标志着其到达了一个新的里程碑。

1.1.0发布包括大量重要的变化，Noelios Technology博客上对其进行了详尽的说明：

• 对HTTP有了更深广的支持，比如部分下载、可恢复上传和内容完整性验证。
• 提供了业界对WADL规范最好的支持，可以为REST APIs提供自动且同步的文档。可以生成XML格式的WADL文档，同时还能借助于来自Yahoo!、使用广泛的样式将其即时转化为HTML格式。
• 首个对新JAX-RS 1.0规范的完整实现之一，该规范提供了面向注解的开发方式。
• 提供了新的Restlet-GWT模块，可以使Restlet API的客户端连接到流行的Google Web Toolkit 1.5 JavaScript平台上，这样我们就可以从Web浏览器调用RESTful应用了。
• 提供了新的扩展，可以更轻松地与JAXB 2.1、JiBX 1.1、Spring 2.5、OAuth、OSGi、Oracle XDB及SSL技术集成。
• 对Atom Syndication XML格式及Atom Publishing协议支持的改进。这两种格式化和解析现在都可用了。
• 基于JavaMail的新的POP3连接器，可以以RESTful形式访问远程邮箱。
• 提供了新的Grizzly HTTP服务连接器，首次在Restlet API中完全采取了NIO支持，让可伸缩性和性能迈上了一个新台阶。
• 提供了新的内部HTTP客户端和服务连接器，以简化开发阶段（零配置）并使得部署更加快捷。

Restlet框架可以运行在任何Java Servlet容器中（通过RestletServlet），也可以作为独立的Java应用来运行（这样省去了很多部署和配置选项）。

上面提到的与Restlet 1.1一起发布的NIO HTTP服务连接器是提供给独立Java版本的Restlet的，它基于用于GlassFish中的Grizzly NIO框架。

上个月发布的JSR-311定义了JAX-RS 1.0规范。如上所述，Restlet支持该规范，而且Restlet的主开发者Jérome Louvel还是该JSR专家组的成员。

InfoQ有幸采访了Restlet项目的领导者Jérôme Louvel，对该发布进行了了解。首先，我们问到了对JSR 311的支持：

我们已经在JSR 311专家组中占据了一席之地，可以向规范领导者提供一些重要的反馈。在这个过程中，Restlet API还是我们重要的灵感来源。我们开发了第一个针对Java的REST框架（在2005年底发布），根据多年的经验，我们能够向Restlet用户提供JAX-RS支持。

因此，我们非常高兴地宣布在最新的Restlet 1.1版中发布了JAX-RS 1.0（由JSR 311定义的API）的完整实现。这是Stephan Koops围绕其硕士论文而努力工作的结果。Stephan还会继续与Restlet社区一起完成该实现的开发工作。

他的下一个目标是借助于JCP scholarship program获得对TCK的访问，并得到针对Restlet的JAX-RS扩展。但我们已经对当前的实现状态感到非常满意，该实现使用了很多来自Restlet API的特性，比如连接器（像Jetty、Grizzly及Simple）和Restlet服务（比如将URI文件扩展转化为恰当的HTTP内容头）的有效性。

接下来，我们问询了Jérôme Louvel何时使用JAX-RS，何时使用本地Restlet API？

你需要了解几个方面才能做出选择。

首先，我们手头上有两个完全不同的设计。如果使用核心Restlet API，我们就会遵循一个传统的面向类的设计，Servlet API开发者对此会很熟悉。基本上所有重要的REST和HTTP概念都会在API中有一个相应的Java类，这样就可以很直观地将理论和协议映射到Restlet特性上。

这会产生一个简洁、可重用、可扩展的框架。例如，我们可以将Restlet应用部署到各种环境下，如Servlet容器、OSGi内核、Spring及Guice IoC容器、独立的JVMs、Groovy、Scala或是JAIN/SLEE。我们甚至还将Restlet API连接到了GWT 1.5（Google Web Toolkit）上，这使得Web浏览器可以与任何RESTful后端友好地进行交互，而这与默认的GWT-RPC解决方案是完全不同的。我们还打算在接下来的1.2版中将Restlet API与Google Android连接起来！

另一方面，JAX-RS采取了一个全新的面向注解的设计。该设计起始于领域对象（POJOs），对其注解以描述它们应如何暴露成一个REST API。理论上，同一个POJOs还可以被注解为JAXB来描述其应如何序列化成XML或JSON。

然而，在实际的REST应用中，你很快就会发现光对现有的领域对象注解是不够的。REST对Web应用来说是一种全新的思考和设计方式：我们称之为面向资源的设计。它与面向对象有一些相似点，但却用开放的状态描述代替了受保护的封装，其识别是基于URI的，并且接口是统一的（基于HTTP方法）。更重要的是，REST层上的资源与支持的领域对象之间的粒度是不同的，这需要我们定义一套新的资源类。相对于注解这些资源类，我认为让他们继承基础的Restlet资源类会更简单，也更强大。

现在，作为一个JCP批准的标准，一些新项目有时会需要JAX-RS，尤其是因为它将成为即将到来的JEE 6标准的一部分。一些公司总觉得使用JAX-RS API更舒服一些，因为JAX-RS API带给他们这样一种感觉：可以将其代码从JAX-RS的一种实现转变为另一种实现，这保护了其代码免受供应商的利益之争。

然而，相对于JEE首次制定时的私有软件时代，当今的开源年代这已经不那么重要了。看看Spring、Hibernate、Groovy是如何改变Java世界的吧。同样在实践上，每个供应商都在诱惑你使用一些非标准的特性，像并非JAX-RS 1.0组成部分的客户端支持，因此这还是会引入一层供应商独有的东西。

最后，Restlet API的特性范围大大超出JAX-RS的特性范围。我们对客户端和服务器端应用都提供了支持，同时还支持几种协议（HTTP、SMTP、POP3、 FILE、JDBC等）的连接器，这些都是通过对HTTP语义的直接映射实现的，所有的内容都使用一个统一的API。我们还提供了一个完整的Servlet API的替代方案，该方案具有更加动态和灵活的URI映射、对连接器的编程式支持、认证及虚拟主机。

Restlet API还提供了操作静态文件目录的类，它们可以自动地更新内容并支持远程更新。它还提供了建立反向代理所需的一切，这样你就可以从你自己的Web浏览器应用中访问外部的REST APIs了。

最后，如果你的项目需要JCP标准的支持或者你更喜欢注解的编程风格，那么我推荐你使用我们的JAX-RS。在其它情况下，我推荐你使用核心Restlet API以获得对REST/HTTP更广泛和直观的支持，同时也可以使用更多的部署选项。

最后，我们了解了关于Restlet社区的更多信息：

Restlet代码集有8个提交者。其中2个核心提交者由Noelios Technologies资助，该公司驱动了这个项目。他们负责Restlet核心（API与引擎），以及大量扩展、构建过程和与外部贡献的集成。自从该 项目首次发布以来，已经有大约160个开发者为该项目作出过贡献！

我们还有6个扩展提交者，他们负责特定的扩展，如JAX-RS、GWT及XDB（Oracle）。这些提交者要么是个人，要么是由其它合作公司（比如Solertium及曼彻斯特大学）资助的开发者。

最重要的是，Restlet是一个属于用户和贡献者的社区，他们互相支持，齐心协力地推动Restlet项目沿着最适合他们项目需要的方向发展。

查看英文原文：Restlet 1.1.0: Improved Flexibility and Specification Support