对于 Java 中的 RESTful 服务，JAX-RS 是否比 Swing、Grails 或 Play 等 MVC 框架更好？
例如，Play-framework 支持如下所示的 RESTful 服务：Play 上的 RESTful！框架
这与 Jax-RS Jersey 实现之类的东西相比如何？像 Play 这样的框架是否因为它有很酷的花哨功能而围绕 Jersey 运行，并且它也支持 REST？
开发人员的生产力很重要，但正确的实施也很重要。也许对纯 REST 服务使用 MVC 框架是“错误的”？
请注意，只有 RESTful 服务，根本没有 UI 组件。
For example, Play-framework supports RESTful services like this: RESTful on Play! framework
How does this compare to something like Jax-RS Jersey implementation? Does a framework like Play run circles around Jersey because of all it's cool bells and whistles, and it does REST too?
Developer productivity is important, but so is a proper implementation. Perhaps using an MVC framework for REST only services is 'wrong'?
Note, only RESTful services, no UI components at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
尽管为 RESTful 服务使用 MVC 框架并没有“错误”，但与使用 JAX-RS 实现相比还是有一些优点和缺点。
（免责声明：我只是为了好玩而使用 Jersey 和 Play！，而不是在生产级系统上使用，因此我针对 MVC 与 JAX-RS 更广泛地定制了我的评论。请记住，这些是广泛的概括。
） ——至少那些被认为是开发人员友好且“巧妙”的——通常可以让您不必构建持久层（模型部分）。大多数还使用约定的脚手架或某种形式的配置来简化“路由”请求。缺点是您必须遵守控制器的一些约定，并且通常必须为每个资源编写一个视图（或构建抽象层以避免重写相同的代码）。
JAX-RS 擅长定义路由（使用 Java 注释）以及消除对服务类的任何限制。根据我的经验，这大大减少了样板代码的数量和开发人员的开销。 Jersey 和 Apache CXF 还使用 JAXB 注释处理 XML 或 JSON 序列化，这样就无需在 MVC 上下文中找出视图。这里的缺点是，您必须弄清楚自己的 ORM 或持久层，这可能是好是坏，具体取决于您是在现有数据之上构建还是创建新系统（或使用 JPA/RDBMS 以外的其他系统）例如NoSQL 数据存储）。
我个人的评论：玩吧！是一个非常酷的框架，但我会选择 CXF（或 Jersey）而不是 MVC 框架来构建 RESTful 服务。根据我的经验，这使开发人员能够专注于服务所需的逻辑，并为不同的数据库方法提供了选择。正确的工具适合正确的工作。
Even though it's not "wrong" to use an MVC framework for RESTful services, there are some pros and cons versus using a JAX-RS implementation.
(Disclaimer: I have only used Jersey and Play! for fun, and not on production-grade systems, so I have tailored my comments more generally to MVC vs. JAX-RS. Keep in mind that these are broad generalizations.)
MVC frameworks--at least the ones that are considered developer friendly and "slick"--typically save you from having to build a persistence layer (the model part). Most also simplify "routing" requests using either scaffolding via convention or some form of configuration. The downsides are that you have to conform to some conventions for your controllers and usually have to write a view for each resource (or build layers of abstractions to avoid rewriting the same code).
JAX-RS excels at defining the routing (using Java annotations) as well as eliminating any restrictions on the service class. In my experience, that has greatly reduced the amount of boilerplate code and developer overhead. Jersey and Apache CXF also handle the XML or JSON serialization using JAXB annotations, which eliminates the need to figure out the view in an MVC context. The downside here is that you have to figure out your own ORM or persistence layer, which could be good or bad depending on whether you're building on top of existing data or creating a greenfield system (or using something other than an JPA/RDBMS e.g. NoSQL data store).
My own personal comment: Play! is a really cool framework, but I'd choose CXF (or Jersey) over an MVC framework any day for building out a RESTful service. In my experience, this frees up the developer to focus on the logic needed for the service, and opens up options for different database approaches. Right tool for the right job.
根据经验：对于 Scala，请使用 Play。对于 Java，请使用 Jersey。
您可以使用 Jersey/Scala 和 Play/Java；我都做过。有用。这还不错。但除非你有特殊的理由这样做，否则我不会混合生态系统。 Java 和 Scala 是可互操作的，但它们有不同的生态系统，如果您使用 Scala，我会避免添加 Java 主义，如果您直接运行 Java，我会避免添加 Scala 主义和依赖项。
Jersey 和 Play 的 REST 服务通常很接近。两者都没有真正优于对方的杀手级功能。
Jersey 在注释中定义 URL 映射，Play 在服务范围的路由文件中定义它们。它们与不同的库捆绑或具有不同质量的集成，例如 XML、JSON、数据库、测试、模拟、依赖项注入库和应用程序服务器部署。
Java世界有JMS、Spring、JUnit、jdbi/hibernate/jpa、Jetty/Grizzly。 Scala 世界有 Akka、specs2/ScalaTest、Anorm/slick。 Jersey 更适合第一个世界，Scala 更适合第二个世界。你绝对可以跨越它，但它会有点不太优雅，并且可能需要更多的粘合编码。
As a rule of thumb: For Scala, use Play. For Java, use Jersey.
You can use Jersey/Scala and Play/Java; I've done both. It works. It isn't bad. But unless you have a particular reason to do that, I wouldn't mix ecosystems. Java and Scala are interoperable but they have different ecosystems, I would avoid adding Java-isms if you are using Scala or Scala-isms and dependencies if you are running straight Java.
Jersey and Play are generally close for REST services. Neither really has any killer features over the other.
Jersey defines URL mappings in annotations, Play defines them in a service wide route file. And they bundle or have varying quality of integration with different libraries for things like XML, JSON, database, testing, mocking, dependency injection libraries and app server deployment.
The Java world has JMS, Spring, JUnit, jdbi/hibernate/jpa, Jetty/Grizzly. The Scala world has Akka, specs2/ScalaTest, Anorm/slick. Jersey is a better fit for the first world, Scala for the second. You can definitely cross that, but it will be a little less elegant and might require more glue coding.
JAX-RS 是一个标准，不同的供应商可以创建实现。 Jersey 就是这样的一个实现。其他框架可能会使用 JAX-RS，但不是标准。所以这不是一对一的比较。
我以前从未听说过 Play，但它看起来确实很有趣，比 Jersey 更类似于 Rails 和 Django。我喜欢 Jersey 的一点是，只需添加 JAR 并在 web.xml 中声明一些内容，它就可以集成到现有的 Java Web 应用程序中。我发现 Jersey 和 JAX-RS 令人困惑的是路由。
Play 似乎使路由变得更容易，但是，如果我错了，请纠正我，它似乎是一个全有或全无的框架，不能与同一 Web 应用程序中的其他 servlet 一起使用。
JAX-RS is a standard and implementations can be created by different vendors. Jersey is one such implementation. The other frameworks may make use of JAX-RS but are not standards. So it is not a one-to-one comparison.
I have never heard of Play before but it does look interesting, more akin to Rails and Django than Jersey. What I like about Jersey is that it can be integrated into existing Java web applications by simply adding the JARs and declaring some things in the web.xml. What I find confusing about Jersey and JAX-RS is the routing.
Play seems to make routing easier, however, correct me if I'm wrong, seems like it is an all-or-nothing framework and cannot be used alongside other servlets in the same web application.