views:

811

answers:

4

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?

A: 

It's not on your list but I would recommend resteasy to build your webservices which is pretty easy to use ... just need to use annotations on the methods to deliver the webservices, and also everything you wrote that u want.

Also, if u want a good EJB integration, u can use resteasy with the JBoss Seam Framework

Diego Dias
Thanks. Does resteasy offer something (relevant) Jersy does not?
deamon
I havent used much of jersey so far to make a comparison. InfoQ has an article that tried to do it http://www.infoq.com/news/2008/10/jaxrs-comparison.But as I have seen, people choose its technology based on which one is easier to integrate. If you are using Spring then Jersey would be easier, although if you use Seam, Resteasy is better.
Diego Dias
+1  A: 

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.

Don
Maybe "buggy" is a bit harsh for characterizing Grails, but annoyed me a bit too often. With "I'd prefer JPA over Gorm" I meant that I'd prefer to use JPA syntax and features directly. Gorm is another way to use Hibernate. Thanks for suggesting Play, it looks nice.
deamon
I agree with Don. The main thing that annoys me about Grails is the underlying Spring magic. Grails itself is fine, though not quite as complete as I'd like. (Except you need to `grails clean` a bit too often.)
mcv
+4  A: 

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.

James Strachan
Sounds good. But I think JAX-RS is missing some small helpers like support for templates in different languages, highlighting of form fields with invalid input and so on. Maybe JAX-RS could be a good foundation for a framework like that ...
deamon
+2  A: 

Hi there,

I'd like to mention the Restlet Framework, which was the first REST framework for Java when it launched in 2005. It is mature, scalable, has a large user base and an active community.

Version 2.0 is in final development phase and provides a broad features set including:

  • complete mapping of HTTP concepts in a clean Java API
  • consistent API for client-side and server-side
  • integration with many popular technos (FreeMarker, Velocity, Spring, Jackson, XStream, JAXB, Atom, OData/WCF Data Services, etc.)
  • can be deployed in standalone Java SE, inside Java EE/Servlet container, in Google App Engine, Android and even GWT for which it knows how to automatically serialize beans using deferred binding (similar to GWT-RPC but RESTful)
  • provides many connectors for HTTP, SMTP, POP, JDBC, SIP, etc.
  • complete security package built-in, focused on web security
  • support for JAX-RS as an extension
  • class-oriented API that is predictable, easy to extend and configure (in Java, XML, Spring, Groovy, Scala, etc.) with support for Java annotations when truly useful
  • etc.

Have a look at the project and give it a try: http://www.restlet.org/

Best regards,

Jerome Louvel

Restlet ~ Founder and Lead developer ~ http://www.restlet.org

Noelios Technologies ~ Co-founder ~ http://www.noelios.com

Jerome Louvel