This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Web Services and the fly likes Jersey client architecture question. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Jersey client architecture question." Watch "Jersey client architecture question." New topic
Author

Jersey client architecture question.

Steven Miller
Greenhorn

Joined: Apr 29, 2009
Posts: 4
I've been looking into using Jersey to write some REST web services.

Now I'm thinking about consuming them with another application, and wondered how most people do this. Would you recommend that I use the Jersey client api? That seemed like the easiest, since it will easily get me the data and convert it into web beans (if that's what they are called) that the client can then use, modify and update.

So the real puzzle is that it seems my client needs access to the web beans (XmlRootElement marked POJOs) and resource classes to be used. To do this, I'm thinking I'd need to generate a jar from the web service app that had these objects in them, so that I can then us the Jersey client api. Is this the correct way of thinking? Is there a better way?

If not, I guess I can just always have my client build its own objects from the json or xml that is returned. Just figured I'd ask how people are setting up their projects and deploying things. I obviously don't want two of the same beans in two different places in my source control.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Jersey client architecture question.