9

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.

Community
  • 1
  • 1
mckamey
  • 17,359
  • 16
  • 83
  • 116

2 Answers2

7

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

Christoph Metzendorf
  • 7,968
  • 2
  • 31
  • 28
  • Thanks for your insight. Sounds like your experience mirrors my first impressions pretty closely. I don't need to get dogmatic about REST, but I'd prefer not to have to jump through hoops to tweak headers. Nice to hear that Jersey ended up being a good choice as that is the JAX-RS implementation I've been working with. – mckamey Mar 04 '11 at 21:53
  • I'm curious did you feel like the routing and content-type handling in JAX-RS was sufficient for your REST needs? Also did the extra control end up being too much boilerplate code? Or was it reasonable? – mckamey Mar 09 '11 at 00:46
  • Concerning the routing there are pros and cons of having it defined for each resource. It's less elegant and definitely not convention over configuration. On the other hand it's more obvious, as it's right next to the code. For the content negotiation I've used JAXB classes to automatically generate XML or JSON. I found this even less intrusive as the withFormat technique in Grails. – Christoph Metzendorf Mar 09 '11 at 08:51
  • I've had similar experiences so far. As for content negotiation, I guess I was meaning have you had issues where JAX-RS didn't provide enough control? For example accept type conflicts: http://stackoverflow.com/questions/5250923 – mckamey Mar 10 '11 at 00:48
1

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.

Kaleb Brasee
  • 51,193
  • 8
  • 108
  • 113
  • Especially when JAX-RS feels like MVC minus predefined view and model patterns. Thanks for the gut-check. – mckamey Mar 04 '11 at 01:21
  • Just curious, have you picked an implementation of JAX-RS? I've been thinking about using it in an upcoming Groovy project but haven't really compared the implementations. – Kaleb Brasee Mar 04 '11 at 01:27
  • Jersey is what I've played with the most. I've not used any of the implementations extensions to JSR-311 so that I could "easily" switch between. "RESTful Java with JAX-RS" (http://oreilly.com/catalog/9780596158057/) has a chapter which compares some. Not sure how much has changed since 2009. – mckamey Mar 04 '11 at 02:04