This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

MVCJ

Stefan Tilkov,

Paul Sandoz about Jersey's (the JSR 311 reference implementation's) UI support:

Perhaps a little know fact (I should have blogged about it sooner) is that Jersey has support for the MVC paradigm and pluggable template processing.

Even though I haven't played with it yet, this seems very cool – although one could criticize that the right way would have been to improve the Servlet and JSP APIs, adding UI processing to the JAX-RS API layer is a second best solution I can live with.

On May 26, 2008 9:33 PM, Jason R Briggs said:

I find I still can’t get over the fact that they’ve called the package “javax.ws.rest”, and the byline is “RESTful Web Services made easy in Java”. Do we really have to have the WS association…?

On May 26, 2008 11:23 PM, Stefan Tilkov Author Profile Page said:

Well, you know it’s just Web services in the loosest definition of the term …

On May 27, 2008 5:32 AM, Gavin Terrill said:

I saw this in the early releases of Jersey and wondered… WTF? It’s not like there aren’t already a couple of dozen MVC frameworks out there that do a pretty decent job of the presentation layer. Did they think they could crack this nut better than everyone else as a side effect of building out the JSR 311 reference implementation? My advice: focus on a decent RESTful interface/implementation for Java and don’t allow yourself to get sidetracked with distractions.

On May 27, 2008 11:05 PM, Stefan Tilkov Author Profile Page said:

Gavin - they’ve not tried to force it into the standard, just added it as an option to the RI. I’m happy to be able to play with it …

On May 28, 2008 4:24 AM, Gavin Terrill said:

I guess I should have elaborated on why I think this is a Bad Thing:

  • Having the reference implementation tack on feature not specifically JSR 311 related muddies the waters, causing confusion about what it is trying to do. I can see potential REST adopters (decision makers) taking a look at it and deciding against further investigation because “the way to do the UI is via Yet Another MVC implementation”. Big Co have just gone through the Struts -> Spring MVC transition and are gun shy of adopting another framework anytime soon, no matter how cool it is. I know you don’t have to use it, but busy people don’t have time to sift through what is really part of the spec and what isn’t. I have already seen this play out.
  • The team developing this are a finite resource. If you view the MVC stuff as a distraction as I do, it means that less time is being spent on the JSR 311 stuff. (Having said that, the team is doing a great job of releasing early and often.)
  • I think the reference implementation should be UI agnostic. Better yet, ship some samples that show how it could work with alternate front ends - Spring MVC, AIR, ExtJS etc.
  • I would argue that MVC is an implementation choice relevant to the UI layer. I don’t see it as being crucial to a framework intended to support an API based on the REST protocol. The increased surface area makes it hard to grok core REST principles. Again, I’ve seen the confusion this causes to first time REST developers first hand.

I actually think the MVC approach they have come up with is pretty cool as well (it seems very similar to the way Lift works in this regard), but my preference would be that it be clearly separated from anything to do with the JSR 311 reference implementation.

On June 11, 2008 10:13 AM, Martin Probst said:

I’ve actually used this and implemented a small application that does have a UI.

To adress the concerns: the UI stuff is pretty much separated from the actual javax.ws.rest implementation. And it is designed such that existing templating/UI approaches are to be reused. That is, they don’t implement their own UI framework, but rather make it easy to plug in existing ones. The default implementation shipped simply allows to call out to JSPs, but you could probably easily integrate any of Spring, Velocity, etc.

What’s more annoying is that there is an impedance mismatch between browsers and non-browser clients (user agents). For example, in response to a POST you would usually want to return a 201 Created, with a Location header. But sadly, browsers don’t support this. There are some more problems like this, and I feel it’s not yet really thought out how to solve those issues.