Hi, I am struggling to find documentation for even the simplest example of wiring jersey, spring and hibernate together. Can you point me to a simple example? I don’t mind whether it places the rest annotations in the domain, or uses an intermediate model, any help would be greatly appreciated. Thanks!

I put a layer of Model classes between my domain and my external views because it allows me to refactor with greater safety.

My domain classes tend to evolve over time, as my understanding of the problem domain improves. Automated refactoring tools, combined with the compiler and extensive unit tests, help ensure that this transformation is safe – within the Java code.

If I exposed the domain classes directly, then this refactoring would alter the outgoing XML and JSON (or, in a JSP world, alter the beans injected into the JSP scope). These changes are harder to detect and test to be sure they are safe. In addition, if I’m using the XML as an integration point, I’ll have to go and check other pieces of software.

So I put the model classes in between to allow me the freedom to change the domain without this overhead; refactoring the model classes still requires the discipline mentioned above.

Dave

My solution is not superior, or even suitable for Jersey generally as the JSON it produces would be hard to parse back to Java code, but it’s a bit easier to deal with as a Javascript client. The natural notation sounds interesting, and I will definitely check it out.

Personally, I’m heading down the path of saying that relative URLs within the app aren’t really configuration.

Re: line 17. In an AJAX app, I may want a HTML request to, say, /hotel/1234/ to bring back the content (HTML, CSS, javascript). This content could be entirely static, with all the dynamic behaviour coming from the javascript interpreting the JSON data. Being able to do content negotiation at that level means I can avoid hitting a method that will load content from the database, if that’s not necessary. Of course, in the example above, I don’t do that.

As for discoverable “next actions” – that comes down to what you have in your outgoing model. So, for example, you’d want to put in “link” elements – which presumably would be relative (and another good reason to have the URLs within the app not treated as configuration). You also get some “next actions” via convention – e.g to update a hotel, do a POST.

Also perhaps you can elucidate on the basis of the comment about line 17? Is this related to the mapping of the views from the model class that you mention as being the third thing you like about it? Would this mean, a different method per view rendering even if it’s the same object being rendered?

How does it allow for discoverable ‘next actions’?

In fact, the biggest problem with it I’m having right now is that JAXB doesn’t understand maps properly. This means my model classes look just a little odd when I want a map effect.