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.
--
Nazrul Islam - (408) 276-6468 - Oracle
Jason Lee wrote:
> I have in the past, yes. All that effort will do, though, is
> standardize the Jersey Client API (in some form and with input from
> other client libs), which is what these wrapper classes wrap. When
> that spec is standardized and GlassFish moves to the new spec, the
> client wrappers will be updated to use the new spec.
>
> On 10/10/11 3:50 PM, Nazrul Islam wrote:
>> Jason Lee wrote:
>>> One of the goals for the REST interface for GlassFish 4.0 is to
>>> create a set of client classes that will help hide as much as
>>> possible of the complexities of REST calls, payload processing,
>>> etc. To that end, in the past few days I have committed a fair
>>> amount of code that creates such a client, not only in Java, but
>>> Python as well (Ruby and maybe PHP are in the offing, time
>>> permitting). I've posted a couple of articles showing how to
>>> generate the clients and how to use them:
>>>
>>> http://blogs.steeplesoft.com/2011/10/glassfish-rest-interface-a-client-side-perspective/
>>>
>>> http://blogs.steeplesoft.com/2011/10/glassfish-rest-client-goes-to-the-flying-circus/
>>>
>>>
>>> Two warnings: my attempt at humor is in those blogs :P, and the
>>> code/usage under discussion is still in flux, so things may change
>>> some before the final release.
>>>
>>> I would appreciate any feedback anyone may have on any aspect of
>>> this. :)
>>>
>> This looks nice.
>>
>> JAX-RS 2.0 (JSR 339) is talking about a client API. Have you looked
>> at that? Refer to
>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/22800/STS-22800_1739780.pdf
>>
>>
>
>