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

JAX-RS成为标准已经有一年了，其间出现了不少的实现，比如RESTeasy，CXF以及JerseySUN的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?