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