State of the art Java web framework for RESTful GUI apps? [closed]

Question

Yes, I know, the old question of the best web framework ... but let me explain.

I'm looking for Java Servlet based web framework that allowes RESTful interaktion and is also suitable to build web GUIs.

What I want:

• REST support with http content negotiation and nice URL mapping
• data conversion from request params to domain object (and ideally the other direction too)
• no need to duplicate domain object as interface to the web (like in struts)
• easy EJB integration
• dependency injection should be performed by the Java EE server
• comprehensible code (I don't like Spring MVCs magic wirering of components in the class path)
• easy to configure (what isn't configured in Spring magically is tedious to configure in the container - i'd prefer sometimes direct dependencies)
• the wheel shouldn't be reeinvented, e. g. something like JPA and BeanValidation should be used and not reinvented by the framework, or at least these standards should be easy to use.
• Validation support with display of errors in forms
• support for internationalization

The Candidates:

• Spring MVC is powerful, but I'm tired of Spring configuration and don't like the programming model. I think it is a bit too abstract and flexible and hence requires to much configuration. And I don't like the way Spring MVC uses annotations. But there are also some design flaws like methods that return a value via return and via an output parameter - really ugly! I think it wouldn't be easy to use Spring MVC with Java EE dependency injection, since Spring MVC heavily relies on Spring DI.

• Roo seems to be cool, but it is just another way to create a Spring MVC app and it does some strange things with AOP.

• Struts is somewhat awkward and outdatet.

• Stripes The ActionBean approach doesn't look much better than Struts. I don't like it.

• Grails nice, but buggy (at least before 1.2). Reeinvents the wheel: I'd prefer JPA over Gorm for example.

See also 10 Best Java Web Frameworks

I'm not looking for frameworks with UI state on the Server like Wicket, Tapestry or JSF. I think this approach contradicts fundamental principles of the web!

So what to do? Write a framework from scratch? hmm ...

I'd like to have something like JAX-RS with support for classic browser GUIs. For example the framework should support validation and put validation error into the redisplayed form. Is there something like that? Any recommendations?

Answer 1

I've blogged about using JAX-RS as the unifying web framework in the past. You can pretty much do all you need with JAX-RS; the main downside is all the pieces are maybe not as well documented in one place as with things like Spring MVC, Stripes, Grails, Seam et al.

For views, its pretty easy to use JAX-RS with Jersey and support web UIs in HTML in addition to RESTful services in JSON/XML/whatever. You can reuse JAXRS's elegant content negotiation so HTTP content accept headers are used to decide if HTML or XML is returned etc (plus you can weight HTML on the server side to avoid serving XML to some web browsers which provide odd accept headers - I'm looking at you Safari which prefers XML to HTML!). e.g. adding @ImplicitProduces("text/html;qs=5") to your resource bean will weight HTML higher than any other representation. You can also configure URI postfixes (like adding .html or .xml or .json) to override the content negotiation; which makes testing the different representations in a browser much simpler.

Jersey supports implicit views nicely so you can render views in HTML using any template engine like JSP or Lift templates or whatever; then use the more traditional JAX-RS providers for XML/JSON type marshalling. You can either be explicit with views; or let JAX-RS find your template etc.

To see implicit views in action its probably worth downloading the source for Jersey and looking at the samples, such as the bookstore (search for @ImplicitProduces if you like).

In terms of things like validation, its easy to integrate the Bean Validation JSR into a resource bean; so you can perform custom validation of a resource or DTO or whatever. Similarly there's nice form posting support in Jersey (form beans).

I would recommend using some DI/IoC framework to inject the resource beans with things they need (like database stuff, bean validation stuff or service objects or whatnot). Guice works pretty well with Jersey if you want to avoid Spring; though Spring with JavaConfig does avoid lots of XML.

For complex UIs you probably want to use JavaScript on the client these days. While its easy from JavaScript to invoke restful services (particularly if they use JSON or JSONP) - the missing piece is elegantly reusing RESTful services in Java/JAX-RS from GWT. So far RestyGWT looks the most promising. One day maybe the best JSON marshalling framework, Jackson will have native GWT bindings. The idea would be to reuse DTO objects in GWT on the client side and in the server side JAX-RS - while remaining completely RESTful.

Answer 2

I think your characterization of Grails as "buggy" is a little harsh. Although you encounter bugs when using Grails it's often the underlying frameworks (Spring, Hibernate) or a plugin that's responsible rather than Grails.

Also, given that Hibernate is a JPA implementation, does it really make sense to say that

I'd prefer JPA over Gorm

Anyway, if you really aren't happy with Grails or any of the other frameworks you've mentioned, the Play framework may be worth a look.