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.