例如，Play-framework 支持这样的 RESTful 服务：RESTful on Play! framework
这与 Jax-RS Jersey 的实现相比如何？像 Play 这样的框架是否会因为它的花里胡哨而在 Jersey 周围运行，并且它也适用于 REST？
开发人员的生产力很重要，但正确的实施也很重要。也许将 MVC 框架用于仅 REST 服务是“错误的”？
注意，只有 RESTful 服务，根本没有 UI 组件。
【问题讨论】：
标签： rest grails jersey playframework jax-rs
尽管将 MVC 框架用于 RESTful 服务并没有“错误”，但与使用 JAX-RS 实现相比，也有一些优点和缺点。
（免责声明：我只是为了好玩而使用 Jersey 和 Play!，而不是在生产级系统上使用，因此我将我的 cmets 更广泛地定制为 MVC 与 JAX-RS。请记住，这些都是广泛的概括。 )
MVC 框架——至少是那些被认为对开发人员友好且“流畅”的框架——通常使您不必构建持久层（model 部分）。大多数还通过约定或某种形式的配置使用脚手架来简化“路由”请求。缺点是您必须遵守控制器的一些约定，并且通常必须为每个资源编写一个视图（或构建抽象层以避免重写相同的代码）。
JAX-RS 擅长定义路由（使用 Java 注释）以及消除对服务类的任何限制。以我的经验，这大大减少了样板代码的数量和开发人员的开销。 Jersey 和 Apache CXF 还使用 JAXB 注释处理 XML 或 JSON 序列化，这消除了在 MVC 上下文中找出 view 的需要。这里的缺点是您必须弄清楚自己的 ORM 或持久层，这可能是好是坏取决于您是在现有数据之上构建还是创建新系统（或使用 JPA/RDBMS 以外的其他东西）例如 NoSQL 数据存储）。
我个人的评论：玩！是一个非常酷的框架，但我会选择 CXF（或 Jersey）而不是 MVC 框架来构建 RESTful 服务。根据我的经验，这让开发人员可以专注于服务所需的逻辑，并为不同的数据库方法打开了选项。适合工作的正确工具。
【讨论】：
根据经验：对于 Scala，请使用 Play。对于 Java，请使用 Jersey。
您可以使用 Jersey/Scala 和 Play/Java；我都做过。有用。这还不错。但除非你有特殊的理由这样做，否则我不会混合生态系统。 Java 和 Scala 是可互操作的，但它们有不同的生态系统，如果您使用的是 Scala，我会避免添加 Java-isms；如果您直接运行 Java，我会避免添加 Scala-isms 和依赖项。
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 更适合第二个世界。你绝对可以越过它，但它会不太优雅，可能需要更多的胶水编码。
【讨论】：
JAX-RS 是一个标准，可以由不同的供应商创建实现。泽西岛就是这样一种实现。其他框架可能会使用 JAX-RS，但不是标准。所以这不是一对一的比较。
我以前从未听说过 Play，但它看起来确实很有趣，更像 Rails 和 Django，而不是 Jersey。我喜欢 Jersey 的地方在于它可以通过简单地添加 JAR 并在 web.xml 中声明一些内容来集成到现有的 Java Web 应用程序中。我对 Jersey 和 JAX-RS 感到困惑的是路由。
Play 似乎使路由更容易，但是，如果我错了，请纠正我，它似乎是一个全有或全无的框架，不能与同一 Web 应用程序中的其他 servlet 一起使用。
【讨论】：