• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

REST client not returning JSON values

 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to learn how to bind json values to my pojo class. I created a simple json file with Person information. I want to read in the url and bind each Person object and it's values to my class. However, all that I am receiving are null values and I can't get anything bound.

Here is a simple example of my json file:



Here is my POJO class





Here is my implementation of getting the information



Here is what the print statement above is giving me:

Result:[personId : null ; lastName : null ; firstName : null ; fullName : null ; classification : null ; department : null ; description : null ; email : null ; phone : null ]


Is there something that I have forgotten to do? Like an additional configuration file aside from my applicationContext.xml?

Thanks
 
Marshal
Posts: 28226
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your JSON object appears to represent some kind of class whose attributes are "title" and "PersonList". But then you try to unmarshal it as if it's a PersonList object, which doesn't have those attributes. I'm not very experienced with these things, but that doesn't look right to me. I don't see any bean class with a "title" attribute.
 
laura mccord
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, I'll have to do some clean-up and try it again. But, what happens if I see attributes like "title" that I want to disregard? Is there are way to skip over such tags in xml/json so they don't bind? There are some cases where I won't have control over the Rest service because I'll be grabbing data from a third-party api.

Thanks
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As amit punekar nicely said, "SOAP is a messaging protocol used to communicate with webservices. By that, the request and response messages shall adhere to SOAP standards. Whereas REST is a architectural pattern to implement webservices in which you define URIs to access your webservices according to REST standards", which say that resources may have different representational formats/MIME types.

This means that (1) REST allows the same Representation of a Resource to be received and served in multiple formats, and (2) REST doesn't define any specific format to be used.

Some say that this provides simplicity and flexibility, I say it provides complexity and confusion. And it gets worse as REST standards don't define how formats will be shake-handed between server and client, leaving that for REST implementations like RESTlet or your own (REST is just a pattern and it's not complex, so it's not that hard to implement a simple RESTful WebService over raw Servlet, for example).

Most REST WebServices define formats using content-type HTTP header on each request and response message. That means that server can't know beforehand (before request comes) what format client will use, and vice-versa. And since RESTful communication must be Stateless and information-oriented, we must at best be careful on client requesting server about what content types he accepts and serves to only then send a request.

REST tools for Java use Java annotations to bind content types into methods, so that the same Representation of a Resource can be fed by different methods based on different content types. But again, as REST doesn't enforce anything, server can format a response in a content type format that client isn't repared to parse, and vice-versa. Indeed, this is the sole reason that makes each REST resource require a full Java class to be handled, even REST providing only 4 operations, while SOAP allows a full WebService, full of unlimited operations, be handled by a unique broker class! with all states you want and need to use!

There is WADL, a definition language used for defining representation formats, messages, etc, but again REST doesn't enforce its use (as long as I know WADL isn't even part of REST standard) and no REST tool creates it for you.



You're facing this exact problem. It seems your WebService provider provided you, as a means of format definition, just an example of a JSON message you may receive. And of course REST tools won't build a Java class out of that example for you.

It would be better if provider would provide you, instead of a JSON example of a "representation of a resource", the original class that's being marshalled, and also which JSON marshaller he's using. If you both use Java you can use the same class, and if needed the same marshaller, and you'll hardly have trouble in format regards.

I have a little experience with Axis2 SOAP and have been learning about REST last days, and I'm disappointed on it. Read about it in RESTlet slower than Axis2?. In my benchmark I got satisfied with Axis2's performance, in both XML marshall and demarshall and its built-in HTTP client, while RESTlet built-in client hangs and it's slower overwall. I feel like REST's "simplicity and flexibility" (it's not either of them for me) is a burden that makes everything more complex, and not an advantage,


For your question "But, what happens if I see attributes like "title" that I want to disregard? Is there are way to skip over such tags in xml/json so they don't bind?", you'll have to ask how your JSON marshaller handles that.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic