Grails 与 RESTful API / MVC 应用程序的 JAX-RS
我知道标题可能看起来像苹果和苹果。橘子，但听我说……:)
我正在构建 MVC 应用程序的架构，并考虑将什么用于控制器/服务的核心。该堆栈还将充当 RESTful API，与 UI 同等重要。
我正在缩小我的堆栈范围，使用 Grails 或 JAX-RS 构建（此时我已经排除了其他选项，并且对扩展此列表不太感兴趣）。无论哪种方式，我都会使用 Groovy，并且我的模型和视图实际上不会受到此选择的影响，因此进一步消除了两者之间的一些差异。以下是我一直在思考的优点/缺点，并想知道是否有人有任何其他意见或警告经验。
Grails
- 我不会使用大量的内置 Grails 功能（GSP/SiteMesh、Hibernate、几乎所有插件），所以我担心 Grails 对于我的目的来说可能有点重，
- 我担心我会赢我对处理 REST API 的能力没有足够的控制，因为它非常以视图为中心
- 我已经看到插件质量的不一致，以至于我不确定我是否认为它们是
- 我喜欢的 “专业人士”约定优于配置编辑和刷新，如果我使用 JAX-RS，我可能想要连接类似的东西，
- 我喜欢 grails 命令行来简化它所简化的所有内容，但我担心它可能会妨碍我因为我没有使用尽可能多的堆栈，
- 所以我喜欢脚手架，但是因为我没有使用 Hibernate 或 GSP/SiteMesh，所以它可能无法很好地啮合
JAX-RS
- JAX-RS 是为 REST 设计的。这将使我的 RESTful API 真正轻松实现，因为我可以完全控制
- Groovy 是让 Grails 脱颖而出的重要组成部分，所以即使在 JAX-RS 中我也会从中受益，
- 我喜欢 JAX-RS 不会自动拉取 不幸的是，我可以更好地控制哪些组件输入/输出，
- 因为它不会引入其他所有东西，而我最终需要的任何东西都需要更多的工作，而 Grails 可能有一个插件
- grails 命令行脚手架将会被错过；也许Maven可以填补一些空白
似乎每个创建操作和路由的功能都非常相似（尽管实现风格不同）。事实上，还有其他问题希望触及这一点，所以我不太担心。
I know the title may seem like apples & oranges, but hear me out... :)
I'm building the architecture of an MVC app and considering what to use for the core of the controller / services. This stack will also serve as a RESTful API which will be equally as important as the UI.
I'm narrowing down my stack to be built with either Grails or JAX-RS (at this point I've ruled out other options and am not super interested in expanding this list). Either way I'll be using Groovy, and my model and views will be virtually unaffected by this choice, so that further levels some of the differences between the two. Here are the pros/cons that I've been pondering and was wondering if anyone had any other inputs or caveat experiences.
Grails
- I am not going to use a ton of the built-in Grails features (GSP/SiteMesh, Hibernate, nearly all plugins), so I'm concerned that Grails might be a bit heavy for my purposes
- I'm concerned that I won't have enough control over my ability to handle the REST API since it is very view-centric
- I've seen inconsistencies in the quality of plugins to the point where I'm not sure I consider them much of a 'pro'
- I love the convention-over-configuration & edit-and-refresh, to the point where I'd probably want to wire up something similar if I go with JAX-RS
- I like the grails command line for everything it streamlines, but I'm concerned that it might get in my way since I'm not using as much of the stack
- I like the scaffolding but since I'm not using Hibernate or GSP/SiteMesh it might not mesh well
JAX-RS
- JAX-RS is made for REST. This will make my RESTful API really a snap to implement as I have complete control
- Groovy is an important part of what makes Grails shine, so I'll benefit from that even in JAX-RS
- I love how JAX-RS doesn't automatically pull in a bunch of other things so I can have more control of what components are in/out
- unfortunately since it doesn't pull in everything else anything that I end up needing will require more work, whereas Grails might have a plugin
- the grails command line and scaffolding will be missed; perhaps Maven can fill some gaps
It seems like the capabilities of each for creating actions and routing are pretty similar (although the implementation styles are different). In fact there are other SO questions wish touch upon this so I'm not too concerned.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
去年，我在几个框架（即 Grails、Play!、Spring MVC、Jersey、Restlet）中编写了一个小型 REST 服务原型。在这个问题上，我对 Grails 的感觉是，虽然 Grails 支持 REST 风格的架构，但它并不是真正为此而设计的。我不想在这里变得宗教化，所以如果您只想将资源映射到 URL 和 HTTP 动词，那没问题，但如果您想更深入地研究 REST，并严格控制返回码、位置标头等，您可能仍然会这样做。可以使用 Grails 来做到这一点，但纯 REST 框架可能会更好地支持它。
Grails 还带有很多依赖项，如果您刚开始使用，这可能不是问题，但当您必须将其与现有的遗留组件或框架集成时，可能会导致问题。
在使用的两个 REST 框架中，我更喜欢 Jersey，因为它在我的案例中很有效，而且文档也很好（尽管有点侧重于 Maven 和 Netbeans）。
I wrote a small REST service prototype in several frameworks last year (namely Grails, Play!, Spring MVC, Jersey, Restlet). My feeling about Grails in this concern was that although Grails supports REST style architecture, it isn't really made for it. I don't want to get religious here, so if you only want to map resources to URLs and HTTP verbs your fine, but if you want to dig deeper into REST with tight control over return codes, location headers, etc. you might still be able to do it with Grails, but it is probably better supported in a pure REST framework.
Grails also comes with a lot of dependencies, which might not be a problem if you're starting on a green field, but can cause problems when you have to integrate it with existing legacy components or frameworks.
From the two used REST frameworks, I liked Jersey more, as it just worked in my case and the documentation was good (although a bit focused on Maven and Netbeans).
是的，当您不打算使用模型或视图时，在 MVC 框架上构建确实看起来很繁重。虽然自动装配和简化的配置非常好，但 Grails 仍然会提供许多您不需要的额外内容。
我个人会采取更轻松的方法，将 Grails 排除在外，使用任何独立的库或编写提供您确实想要的功能的自定义代码。 Groovy 站点上列出了许多容器项目，也许 Spring 或替代方案之一会添加对你的架构有一些价值。
Yeah, it does seem heavy to build on a MVC framework when you're not going to use the model or the view. While the autowiring and simplified configuration is super nice, Grails would still be providing a lot of extra stuff that you don't need.
I'd personally take the lighter approach and leave Grails out, using any standalone libraries or writing custom code which provide the features that you do want. There's a number of container projects listed on the Groovy site, perhaps Spring or one of the alternatives would add some value to your architecture.