JSR 311最终草案：RESTful Web服务Java API

去年2月，Sun宣布了JSR 311：RESTful Web服务的Java API。9月23日，规范的1.0草案通过了JCP执行委员会的赞成投票，这基本意味着它现在已经定稿。

JAX-RS是Java中用于实现以HTTP为基础的RESTful Web服务的 基于注解的API。本质上，注解类和方法的信息能让运行时（Runtime）将它们暴露为资源，这种方法和通过Servlet编程模型来暴露类与方法的做 法有很大区别。实现JAX-RS的运行时（Runtime）周旋于HTTP协议和Java类之间，考虑URI、被请求和被接受的内容类型和HTTP方法。 除了Sun提供的参考实现Jersey之外，可用的其他实现（尚在不同的完成阶段）包括：流行的Restlet框架的一部分，JBoss RESTeasy项目和Apache CXFWeb服务栈的一部分。

InfoQ采访了规范带头人，Sun的Marc Hadley和Paul Sandoz，请他们畅谈了他们对JAX-RS和整个过程的想法。

被问到他们对这个结果的心情时，Mark表示他对API最终完成非常满意。他还表示，非常幸运的是，在专家组从事API设计时就有如此多的实现被构 建出来，并且这有助于抚平API中的任何不足。Paul补充说，不少开发者自愿在API的各个版本上工作，采用测试驱动的方式去实现，并提供反馈。

在问及最具挑战性的方面时，Marc指出，一开始很难在API的风格和范围上达成统一：

为了启动这个JSR，我们以一个涉及面很广的提案开了个头。但是，回想起来，我认为我们可能从一个更具体的方面开始构建更好。
在过去的几个月内，我们已经看到了大量对这个JSR的关注，主要挑战是既保证进度又能适应所有新请求。

Paul大胆地对JSR中“J”的某些方面表示了质疑：

可能这显得有点儿异端，但是有时我发现当前的Java语法本身有点挑战性。但是，通过Java注解、范型和构造器 （Builder）模式，我认为我们把事情降到了一个非常简洁的水平。而且，方便地使用Scala和Groovy来书写这种JAX-RS应用也是有可能 的，这两种语言都支持与Java字节码兼容的注解。

在启动这个JSR的时候，REST社区对它能否符合REST的关键原则表示怀疑。Mark认为这一目标已经达到：

我认为API是鼓励资源中立的观点的，它让开发者自己决定他们资源的标识符和他们支持的方法。对内容协商的说明性支持非常好，缺 省的资源生命周期鼓励无状态的方式。如果我必须指出一个弱点的话，那就是它对“超媒体即状态引擎（hypermedia as the engine of state）”支持有限。虽然我们能很好地支持从请求URI中抽取信息和构造资源URI，在表述（representations）中正确使用超媒体这一任务较多的还是留给了开发者自己去完成。

Paul表示同意：

是的，这可能是最困难的地方了。JAX-RS提供了大量构造URI的方法，但是建模API中还没有类似JAXB这样的URI绑定工具。我认为在这一方面，我们有一些办法可以探索，如 Henry Story的RDF序列化。

问及JSR 311上的工作是否改变了他对Web和Web服务的观点时，Mark表示这印证了他的一个观点，即一个人“无需依赖更复杂的东西就可以用HTTP完成一件非常伟大的事”。Paul指出，REST发明者Roy Fielding的将稀疏位数组（sparse bit array）用于通知便是REST可在将来带来惊喜的一个例子。

我们还向Mark询问了他期望JSR 311如何对即将到来的Servlet规范修订产生影响：

JAX-RS应用可以被Servlet容器托管，因此两者默契合作非常重要。JAX-RS是新的Servlet可插性 （pluggability）框架的一个潜在消费者，因此我们正在着手就此提出我们的要求。一个难处理的地方是，JAX-RS提供了较Servlet更灵 活的URI到资源的映射方式，这对联合使用说明性的Servlet安全和JAX-RS来说是个挑战，因此我们也在从事这方面的工作。

最后，Mark证实Jersey不“只是”一个参考实现，而且完全可作为产品使用，并且已经有实际的部署了。他还指出，Jersey将是Glassfish JSR 311实现，而这正是Jersey需要达到产品质量的原因。Paul强调了另一原因：

定期发布规范和实现的试验版本（early access）一个好处就是，这让APT和实现都能及早和频繁地接受测试的考验:-)

你可以联机阅读这个规范；Jersey参考实现可从java.net获得，并在Java 5或更高版本上运行。

查看英文原来： JSR 311 Final: Java API for RESTful Web Services