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

阅读数:408 2008 年 11 月 12 日

话题:JavaWeb框架REST语言 & 开发架构

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