dev@glassfish.java.net

Re: Client Classes for the REST Interface

From: Jason Lee <jason.d.lee_at_oracle.com>
Date: Mon, 17 Oct 2011 08:41:00 -0500

On 10/14/11 7:01 PM, Nazrul Islam wrote:
> If you look at slide 9 of JAX-RS 2.0 presentation
> <https://oracleus.wingateweb.com/published/oracleus2011/sessions/22800/STS-22800_1739780.pdf>,
> it will give you a custom object (Money in the example) as long as the
> message body write is provided. The API seems to takes the custom
> class (Money.class in slide 18) to do the marshal and un-marshaling.
> After talking to Mitesh, what became obvious is that our REST APIs end
> points are returning action reporter which is a generic bag of
> properties. Lets talk next week after Mitesh and others have some time
> to think about the proposal.
Right. We're doing exactly what they're doing in the slide, except
we're returing a Reponse object, rather than an entity. We wrap the
entity, an ActionReport, in the Response, bu this approach allows us to
manage the status code we return. At one point, Ludo considered using
JAXB to manage the marshalling/unmarshalling but decided that it was
"too heavy". We *could* use to return more direct ConfigBean
representations (though we'd probably still need to stick with
ActionReports for the CLI endpoints), but doing that would break
backwards compatibility, which would pose a huge problem for the
Administration Console. Either way, we'd likely still need something on
the client side to make using the REST interface a little simpler (i.e.,
wrapping the HTTP calls, JSON/XML parsing, etc), which is what these
wrappers are intended to do.

-- 
Jason Lee
Senior Member of Technical Staff, Oracle
GlassFish Team
Phone +1 (405) 216-3193
http://blogs.steeplesoft.com