Grails vs. JAX-RS for RESTful API / MVC App

Question

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.

Answer 1

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).

Answer 2

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.