Jason Lee wrote:
> I don't see how the standardization of the Jersey Client affects the
> API/interface of these generated GF wrappers. The Jersey Client, or
> the forthcoming JAX-RS client library, is simply an API that abstracts
> all of the HTTP-specific code for accessing a remote REST resource.
> The generated wrappers provide classes that mimic the interface of the
> server-side classes, and happen to use, in the Java case, the Jersey
> Client to handle the network layer code (in Python, which has the same
> interface, the network is handled by Python-specific code, for
> example). I *do* have an example of interacting with GlassFish in
> Java using the Jersey Client:
>
> http://blogs.steeplesoft.com/2011/02/glassfish-3-1-rest-and-a-secured-admin-user/
>
> http://blogs.steeplesoft.com/2011/02/glassfish-3-1-rest-and-secure-admin/
>
> Each API has its place, but one builds on the other
> HTTP->Jersey/JAX-RS Client ->GF REST Wrappers.
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.
--
Nazrul Islam - (408) 276-6468 - Oracle