例如，Play-framework支持这样的RESTful服务:RESTful on Play! framework
这与Jax-RS Jersey实现之类的东西相比如何？像Play这样的框架是否因其酷炫的功能而在Jersey周围运行，并且REST也是如此？
开发人员的生产力很重要，但正确的实现也很重要。也许将MVC框架用于仅REST服务是“错误的”？
注意，只有RESTful服务，根本没有UI组件。
最佳答案
尽管将MVC框架用于RESTful服务并不是“错误的”，但与使用JAX-RS实现相比还是有一些优缺点的。
(免责声明:我只是出于娱乐目的而不是在生产级系统上使用Jersey和Play !，所以我更一般地针对MVC和JAX-RS定制了我的评论。请记住，这些是广泛的概括。)
MVC框架(至少那些被认为对开发人员友好且“精巧”的框架)通常使您不必构建持久层(模型部分)。大多数还使用通过约定的脚手架或某种形式的配置来简化“路由”请求。缺点是您必须遵守某些 Controller 约定，并且通常必须为每种资源编写一个 View (或构建抽象层以避免重写相同的代码)。
JAX-RS擅长定义路由(使用Java注释)以及消除对服务类的任何限制。以我的经验，这大大减少了样板代码的数量和开发人员的开销。 Jersey和Apache CXF还使用JAXB批注处理XML或JSON序列化，从而无需在MVC上下文中找出 View 。缺点是您必须弄清楚自己的ORM或持久层，这取决于您是在现有数据之上构建还是在创建未开发的系统(或者使用JPA/RDBMS之外的其他东西)而定，这可能是好事也可能是坏事例如NoSQL数据存储)。
我个人的评论:玩!这是一个非常酷的框架，但是我每天都会选择CXF(或Jersey)而不是MVC框架来构建RESTful服务。以我的经验，这使开发人员可以腾出时间专注于服务所需的逻辑，并为不同的数据库方法提供了选择。适用于正确工作的正确工具。
关于rest - 对于Java中的RESTful服务，JAX-RS是否比诸如Swing，Grails或Play的MVC框架更好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6550760/