On 10/13/11 5:04 PM, Nazrul Islam wrote:
> Hi Jason,
>
> Thanks for looking into JAX-RS 2.0 (JSR 339). The question I was
> asking is slightly different. If we have the standard JAX-RS client
> APIs, do we still need the GlassFish REST APIs? How much end user pain
> point are we addressing with the GlassFish REST APIs? Could you put
> some color on that? For example, could you show the blog examples
> using JAX-RS client APIs? Thanks in advance.
>
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.
--
Jason Lee
Senior Member of Technical Staff, Oracle
GlassFish Team
Phone +1 (405) 216-3193
http://blogs.steeplesoft.com