JAX-RS，或者说 RESTeasy 不是 RESTful?

JAX-RS 成为标准已经有一年了，其间出现了不少的实现，比如 RESTeasy，CXF 以及 Jersey SUN 的 JAX-RS 参考实现。等它最终被批准的时候， Stefan Tilkov 采访了该规范的领导 Marc Hadley 和 Paul Sandoz 对于 JAX-RS 的看法：

当这一 JSR 发起的时候，REST 社区里对于它是否遵循了 REST 的关键原则存在怀疑。

Marc 认为这一目标已经达成：我认为该 API 鼓励以资源为中心的视角，并促使开发者考虑他们资源的标识和所支持的方法。对内容协商的声明式支持也工作得很好，默认的资源生命周期鼓励无状态的方式。如果我必须指出一个弱点的话那就是对于超媒体作为状态引擎的支持有限——尽管我们对从请求 URI 里抽取信息和构建资源的 URI 提供了良好的支持，但对于开发者恰当地使用超媒体作为表示仍有不少欠缺。

Paul 表示同意：是的，这恐怕是最困难的部分。JAX-RS 提供众多构造 URI 的方法，但没有一个有着建模 API，比如 JAXB 的 URI 绑定设施。我认为在这一方面我们有一些工作可以探索，比如 Henry Story 的 RDF 串行化。

Java 社区在过去的 12 个月里明显的感受到了基于 JAX-RS 的项目快速的增长，大部分认为这是向正确的方向迈出了一步。然而，并不是每个人都认同，最近 restfulie 项目的领导 Guilherme Silveira 发表了一篇有趣的文章，将它的项目与 RESTeasy 进行了对比，尽管其后的一些评论指出，这应该被看作是 JAX-RS 与非规范实现的对比。摘自 resfulie 网站，其目标可以概括为：

通过 HTTP 的 CRUD 是通向使用资源和成为 RESTful 的重要一步。另一个重要的步骤就是使用基于超媒体的服务，而 Restfulie gem 就能让你快速的做到这点。

文章中，Guilherme 指出了 RESTeasy[JAX-RS] 所存在的一些问题，他认为这些问题是使得 RESTeasy 违背了 RESTful 而 restfulie 所避免的：

• 强耦合以及超媒体无感知：“到目前为止，Resteasy 要求你创建一个将任一资源操作映射到一个特定方法的接口，使用 @VerbName 和 @Path 注解来指定合适的目标 URI。”
• RESTEasy 不是 Roy 的 REST：按照 Guilherme 的说法 RESTful 系统不应该使用早期绑定，这将导致强耦合的系统。“使用 @VerbName+@Path 的注解的 Java 接口意味着早期绑定，意味着尝试努力去描述什么方法应用于什么 URI，更紧密的耦合，更少有空间去演变你的服务端系统。”
• 服务端：“RESTEasy 不为超媒体内容提供任何默认的接口，而 JAX-RS 默认支持 JAXB：原始 xml。如何使用超媒体系统来创建松散耦合的系统取决于 (优秀) 的程序员。"
• 语言：“Restfulie 的方案中另一个关键点就是它是相对 Java 独立的。每个月我们都能看到大量的使用其它语言开发的集成软件:Restfulie 已经能够帮助 Java 和 Ruby 开发者。”

Jim Webber ，他的言论对于 Restfulie 产生过影响也参与到了这番讨论中来：

整体来说我认为他的分析是准确的：RESTEasy 没能提供对超媒体开箱即用的支持，超媒体不是别的而正是 RESTful。

然而，他接下去说：

但我不认为这是 RESTEasy 的错误。实际上，在 RESTEasy 所身处的奇异世界里，我认为它已经是一个模范公民了。处于企业与 JCP 的夹缝中，一个实用的 Java 供应商，除了遵循 (并影响) 相应的 JSR，还能做出什么其它选择呢？所以这不是 RESTEasy(或者 Jersey 或者 CXF) 的错误，而是由于这种委员会驱动的流程，有着不同的目标以及对 REST 的理解差次不齐的人们被召唤到一起以得出最小的公分母，即 JAX-RS(蹩脚的名字，JAX-RS 顶多不过为 Web 服务提供了一个可编程的层次)。

Bill de hora 在对这篇帖子的评论中表达了不同的看法：

我读过这篇帖子也读了 Guilherme 的帖子，也看了他的框架，并没什么实质性的内容。我明白 JAXB == bad，但是我在服务端和客户端一直使用 Jersey，也从未或者必须跟 JAXB 打交道——这对于实现而言是内部细节 (蹩脚类型系统的变换糖)。那我们不是也可以肆意抨击几乎“任何”其它的“web”框架吗？只要想想我们使用 HttpClient 或者 java.net.* 的乐趣就行了。今天我还在 Abdera 和 Jersey 的基础上增强了一些不错的客户端代码，而底层的东西是链接驱动的。它工作得很棒。如果问题是对于超文本驱动的系统 OO 的模式很差劲的话我倒可以接受这一点…

Stefan Tilkov 接着说：

Restfulie 作出了一些十分特别的决定，并得到了 RESTful 的解决方案。但它却不是一个构建 (任何类型)RESTful 系统的通用方案。我不认为它具有竞争性，他们处理的是不同的问题域。

就是 John Nackman 在 Guileherme 的原贴上所提到的那样…

有意思，但这不是一个客观的分析，不是吗？至少在 RESTEasy 这一部分你忽略了它是基于标准的。或者说你认为标准对于开发者来说不重要？我认为一种更为彻底和客观的讨论会对社区更为有益。

那么除了激起围绕原始的帖子是否准确以外，这是否意味着 JAX-RS 留下太多不确定的东西呢？开发者是否对于现有的实现期待过多？我们把最后发言的机会留给 Bill Burke，RESTeasy 的领导：

RESTEasy 和 JAX-RS 存在有助于你编写 RESTful 的 web 服务和客户端。它是一个工具，超媒体大多是应用特定的，所以我的看法是，一个框架所能做的是有限的，否则，将造成应用的过度设计。REST 是帮助你编写分布式接口的架构性指导方针，而不是帮助你编写和设计代码的指南。我参与到 JAX-RS 是因为我觉得它是最不具侵入性的一种帮助你编写 RESTful 服务的方式。它在如何实现RESTful 服务方面给予了开发者极大的灵活性。实现是这里的关键字。

请留意，我们随后将发布对 Guilherme 单独的访问。

查看英文原文： Is JAX-RS, or RESTeasy, un-RESTful?