WebSphere 上的 Jersey 或 Wink
我们正在研究使用哪个 REST 框架以及在哪里运行它。
给定现有的 WebSphere (6.1.0.17) 环境，您会使用 Jersey of Wink 吗？
或者您会推荐一个不同的平台吗？
We are looking at which REST framework to use and where to run it.
Given an existing WebSphere (6.1.0.17) environment would you use Jersey of Wink?
Or would you recommend a different platform?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
作为第三个选择，为什么不使用 Spring 自己的 RESTful 功能春季MCV。这很容易编码、测试和维护，并且（显然）开箱即用地适用于 Spring。基于 Spring REST 管理代码的便捷性得益于基于 MVC、IoC 和注释的架构。您可以选择一流的解决方案来增强您的解决方案，例如用于序列化的 XStream、Jackson JSON支持，Springs 拥有用于 REST 客户端或单元测试的 REST 模板。
Spring MVC 的 REST 功能的核心是将 REST 作为一种架构而不是一种协议来处理，并将其与其他经过验证的方法（例如 IoC 和 MVC）很好地融合在一起。在考虑框架时，以下 REST 试金石测试很有用：请参阅 innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html。Springs 方法检查更多的框，这要归功于它有效的内容交付。
所有这些框架都依赖于 HATEOAS 支持，这是一种 REST 响应包含与客户端当前可以从此资源执行的所有操作相对应的链接的方式。大多数框架承诺很快就会引入这一点，但需要批判性的眼光来了解实现这一点的最佳方法是什么。
在交付 Wink 和 Jersey 等 JAX-RS 解决方案时，我发现更多地强调遵守 Java 标准，而架构的灵活性较低（例如使用其他第 3 方包）。如果需要遵守 JAX-RS，请考虑 Restlet、Wink 或 Jersey。否则，也许值得考虑 Spring MVC 的 REST 支持。
我已将这种解决方案部署到 WAS 7，没有任何问题或依赖性冲突。
As a third option why not use Spring's own RESTful features in Spring MCV. This is easy to code, test and maintain and (obviously) works for Spring right out of the box. The ease of managing code based on Spring REST is due to an architecture based on MVC, IoC and annotations. And you can choose best in class solutions to enhance your solutions such as XStream for serialization, Jackson JSON Support, and Springs own REST Template for a REST Client or unit-tests.
At its heart Spring MVC's REST features deal with REST as an Architecture not a Protocol and blends it well with other proven approaches such as IoC and MVC. When considering a framework the following REST litmus test is useful: see innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html.Springs approach checks more of the boxes, thanks to it's effective content delivery.
One thing all these frameworks fall down on is HATEOAS support, a way of in which the REST response contain links that correspond to all the actions that the client can currently perform from this resource. Most frameworks promises to introduce this soon, but a critical eye will be needed to understand what the best approach to this will be.
When delivering JAX-RS solutions such as Wink and Jersey, I've found more emphasis on conforming to a Java standard and less flexibility in the architecture (such as using other 3rd party packages). If conforming to JAX-RS is a requirement consider Restlets, Wink or Jersey. Otherwise, maybe it's worth considering Spring MVC's REST support.
I've deployed this kind of solution to WAS 7 without any issues or dependency conflicts.
我没有使用 Wink 的经验，但我可以分享一些在 Websphere 上使用 Jersey 的经验。
优点...非常容易使用，我花了 5 分钟来熟悉，我已经准备好编写我的第一个 hello world。 Jersey 会根据您的
资源包自动为您生成WADL ，尽管非常基本...但您可以自己自定义 WADL 文档。缺点...叹息，我喜欢 Jersey，但是有了 Websphere，它几乎让我哭了。首先（这与Websphere无关），我在我的项目中使用Spring，我使用的Jersey版本是1.2。问题是发行版使用 Spring 2.5，而我使用 Spring 3.x。因此，我撤出了 Jersey 的 Spring 2.5 以使用 Spring 3.x。一切正常。然而，Jersey 测试框架开始失败。我无法再启动内置 Grizzly 服务器来测试我的 Web 服务。其次，我目前使用的是使用 JDK 5 的 Websphere 6.1。我相信 1.2 之后的所有 Jersey 版本都是用 JDK 6 编译的...这意味着，在我的公司升级到 WAS 7 之前我很不幸。
这确实是一个非常稳定的 Rest 框架，非常易于使用...但就我而言，我只是感到沮丧，因为所有现有的 Web 服务单元测试目前都被注释掉了，因为我将 Spring 版本升级到了 3.x。我确信最新的 Jersey 版本现在应该使用 Spring 3.x，但我无法使用它们，因为我仍在 WAS 6.1 中使用 JDK 5。
所以，由你来决定。顺便说一句，我在 WAS 6.1 中运行的项目中仍在使用 Jersey 1.2。
I have no experience in using Wink, but I can share some of my experience in using Jersey running on Websphere.
The pros... very easy to use, it took me 5 minutes to get familiarized and I'm ready writing my first hello world. Jersey does automatically generate WADL for you based on your
Resourcespackage, albeit pretty basic... but you can customize the WADL documentation yourself.The cons... sigh, I like Jersey, but with Websphere, it almost made me cry. First (this is not related to Websphere), I'm using Spring in my project and the Jersey release I use is 1.2. The problem is that release uses Spring 2.5 whereas I'm using Spring 3.x. So, I pulled out Jersey's Spring 2.5 to use Spring 3.x. Everything works fine. However, the Jersey test framework started to fail. I'm not able to boot up the built-in Grizzly server to test my web services anymore. Second, I'm currently tied to Websphere 6.1 which uses JDK 5. I believe all Jersey releases after 1.2 are compiled with JDK 6... that means, I'm out of luck until my company upgrade to WAS 7.
It is indeed a very stable Rest framework, very easy to use... but in my case, I'm just bummed out because all existing unit tests for the web services are currently commented out because I upgraded my Spring release to 3.x. I'm sure the latest Jersey release should be using Spring 3.x by now, yet I can't use them because I'm still using JDK 5 in WAS 6.1.
So, it's up to you to decide. By the way, I'm still using Jersey 1.2 in my project running in WAS 6.1.
在 websphere 6.x 上，首选方法是 jersey，因为它更容易实现，并且支持 JAX-RS 1 和 2。（注意 JVM 版本问题，Websphere 6 可能不支持最新版本）
现在从 Websphere 8 开始。 x IBM 引入了 Apache Wink，如果与 jersery 一起使用，它实际上会带来依赖性和类加载器问题（因为 JAX-RS 1 和 2 的接口实现相同）。
有很多关于如何克服这个问题并使其发挥作用的例子，但我认为不值得，也许 Wink 在 websphere 中会有更好的性能。
On websphere 6.x the prefered method is jersey because it is easier to implement and it supports JAX-RS 1 and 2. (Watch out for the JVM version issues, Websphere 6 might not support the latest version)
Now starting in Websphere 8.x IBM introduced Apache Wink that will actually bring dependency and classloader issues if used together with jersery (because of the same interface implementations for JAX-RS 1 and 2).
There are a lot of examples on how to overcome this issues and make it work but I don't believe is worthy and perhaps Wink will have a better performance within websphere.
IBM 建议使用 Apache wink。事实上，IBM 有自己的 Apache wink 实现。
IBM recommends to use Apache wink. In fact, IBM has his own implementation of Apache wink.
我投票给眨眼。
原因：
I vote for Wink.
The reasons: