正如某人在别处说的，关于公交车，有一个奇怪的现象：你等了很久一辆不来，最后却一下来了三辆！ JAX-RS 实现貌似也碰到了类似的问题。目前我们有：
- CXF —— XFire 和 Celtix 的合并（一个由 IONA 赞助的开源 ESB，最初寄存在 ObjectWeb 上）。
- Jersey ——Sun 公司的 JAX-RS 参考实现。
- RESTEasy ——JBoss 的 JAX-RS 项目。
- Restlet ——也许是最早的 REST 框架了，它 JAX-RS 之前就有了。
尽管围绕着REST 存在各种各样的争论，但JAX-RS 提供了Java 语言所需的 REST 支持这一点是无可争议的。如果你是 REST 新手，你会选择哪种实现呢？嗯， Solomon Duskis 试图解答这一问题。他还在 dzone 上指出： > 我想就以下几个“纯”JAX-RS 以外的方面对各 JAX-RS 实现进行比较。
这些方面包括：
- 产品成熟度
- 服务端集成策略
- Java 客户端 API
- 可配置能力
- 安全性
- 性能
Solomon Duskis 说“Jersey 的用途是作为一个参考实现。RESTEasy 是新思想的游乐场。CXF 是在 IONA 支持下的‘企业版’。Restlet 项目诞生的目的是增加一种 RESTful API 选择。”然而，Bill Burke 在博客评论中反击道:
RESTEasy 不仅仅是新思想的游乐场。其实，我们将很快在 JBoss 里支持它（一拿到 TCK 就可以），而且我们很多大客户都在催促我们提供 RESTEasy 支持。
在易用性方面，Solomon Duskis 说： > 你所面临的问题是选择一种实现。我觉得 Jersey 的确很容易上手，不过 Bill Burke 会说 RESTEasy 同样很简单。它们都可以与 EJB 一起使用。 不过，使用 Jersey 的话，搭建与运行测试服务很容易，如果你下载 NetBeans 的话更是如此。我第一次用 Jersey 和 NetBeans 时，不到半个小时就测试并运行起来了，包括下载、安装及代码浏览等。
Sun 公司的人很想把 Jersey 与人们关于“参考实现”的传统看法区分开： > 你在谈到“产品用途”时，应当将 Jersey 看作一种立马可投入使用的产品（事实上下个月它就要随 GlassFish v3 Prelude 版捆绑发布了）。Jersey 团队花费了相当多的时间来测试并改善代码，以免去其作为“参考实现”的印象！:)
Solomon Duskis 打算对这几个方面进行研究，然后将结果发布在博客里。一篇名为《JAX-RS Spring 集成》的文章已经发布出来了。 > 现在的四种JAX-RS 实现均提供Spring 集成，连JBoss 的RESTEasy 都是。
接着，他对集成作了相当简短的介绍。不过正如 Paul 所指出的，Solomon Duskis 在讲述 Jersey 时引用的是过时的资料。这比较遗憾，因为我们需要的是一个深入彻底的比较。Solomon Duskis 最后说： > 四种实现均具有相当出色的 Spring/JAX-RS 能力，但我认为 CXF 是“JAX-RS 产品里 Spring 集成做得最好的”。
不过显然这只是他的个人看法，其他人肯定会有不同意见。比如 Bill Burke 就问道： > 我没看出 CXF 在 Spring 集成方面比其他产品优越在哪里。我不明白为什么所有额外的 CXF 专用 XML 都被放在一个 Spring XML 文档里。RESTEasy 和 Jersey 提供的 Spring 集成要比 CXF 的侵入性更小。如果我没搞错的话。
对此，Solomon Duskis 回复说： > 如果各个类有一个简单的配置，能够满足超过 90% 的需要，那么标注驱动的方法是可行的。剩下那不到 10% 的部分，需要在不同场合下对同一资源作不同配置。 我知道，根据我所更新的功能的需求与当前部署，我将会需要这种方案。为了通过同样的 Spring XML 文档来部署具有不同配置（如不同的 JDBC 数据源、不同的服务实现等等）的同一个资源，CXF 提供了额外的功能。基本上，大多数情况下，标注的办法是 很好的，但有时，你必须采用外部配置的办法来实现解耦（decoupling）。XML 方案并不如标注一样受欢迎，但它们可以用于更复杂的配置情况。
或许更深入的比较能够揭示出更多的东西来？查看英文原文： A Comparison of JAX-RS Implementations
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论