• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Al Hobbs
  • salvin francis

Jersey client architecture question.

Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic