On Jan 28, 2009, at 12:50 AM, Arul Dhesiaseelan wrote:
> That would be awesome if 2.0 addresses this concern. It opens up
> room for building highly interoperable restful services where
> services are clients too and resource interaction is not limited by
> the client API.
>
> Is 2.0 work done under existing JSR311 or a separate JSR?
>
If JAX-RS 2.0 is undertaken (we have only just submitted the JAX-RS
1.1 maintenance release and no discussions have started on a proposed
2.0) then IIUC it will require a new JSR submission, which will result
in a new JSR number.
Paul.
> -Arul
>
> Marc Hadley wrote:
>> On Jan 27, 2009, at 12:45 PM, Arul Dhesiaseelan wrote:
>>
>>> It would be nice if JAX-RS defined a standard client-side API.
>>> Currently, every implementation (Jersey, Resteasy, Restlet)
>>> provide their own client APIs and it becomes cumbersome for tools
>>> to interface with different implementations and had to use
>>> specific client APIs when working with their resources. HTTP
>>> Client API is one option, but they are not modeled around the
>>> resources which the Jersey client API does it wisely.
>>>
>>> Any plans to provide a standard client API which can interoperate
>>> with various JAX-RS implementations?
>>>
>> Its something we might look at in a 2.0 API. However, I think it
>> could be quite tricky to get consensus around since the existing
>> client APIs are all rather different.
>>
>> Marc.
>>
>>>
>>> Craig McClanahan wrote:
>>>> amsmota_at_gmail.com wrote:
>>>>> Well, it occurs to me that both JAX-RS and Jersey dosen't define
>>>>> client-side API's (however, other JAX-RS based frameworks do,
>>>>> like Restlet and RestEasy, if I'm not mistaken....)
>>>>>
>>>>> So to build a full Web app you have to use Jersey *and*
>>>>> something else...
>>>>>
>>>>> (i'm reading your blog post by pieces, i must say...)
>>>>>
>>>> JAX-RS does not currently define any standard client side API,
>>>> but Jersey most definitely does And it works really well --
>>>> letting you share the provider machinery from the server side.
>>>> You can start with the Javadocs[1], read examples on Paul's
>>>> blog[2], or look at nearly all the unit tests for jersey-server
>>>> -- they use jersey-client to exercise the server side features.
>>>>
>>>> [1] https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/index.html
>>>> [2] http://blogs.sun.com/sandoz/category/REST
>>>>
>>>> Craig
>>>>>
>>>>>
>>>>> On Jan 27, 2009 3:45pm, James Strachan
>>>>> <james.strachan_at_gmail.com> wrote:
>>>>> > I've been pondering this for a little while; is JAX-RS the
>>>>> kinda long
>>>>> >
>>>>> > term replacement for all the zillions of web frameworks out
>>>>> there?
>>>>> >
>>>>> >
>>>>> >
>>>>> > I tend to think, yes it mostly is for most requirements - and
>>>>> we're
>>>>> >
>>>>> > nearly there, just a few things to fix up and improve. I've just
>>>>> >
>>>>> > blogged (a rather long post for me) about it, brain dumping my
>>>>> >
>>>>> > thoughts
>>>>> >
>>>>> > http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html
>>>>> >
>>>>> >
>>>>> >
>>>>> > it could well feed the trolls but it'd be interesting to hear if
>>>>> >
>>>>> > others have been having similar thoughts (or maybe I'm just
>>>>> smoking
>>>>> >
>>>>> > crack :). From seeing folks hit similar issues to me in the
>>>>> implicit
>>>>> >
>>>>> > views / static files /JSP mappings areas - it looks like at
>>>>> least a
>>>>> >
>>>>> > few folks are trying to do similar things.
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > James
>>>>> >
>>>>> > -------
>>>>> >
>>>>> > http://macstrac.blogspot.com/
>>>>> >
>>>>> >
>>>>> >
>>>>> > Open Source Integration
>>>>> >
>>>>> > http://fusesource.com/
>>>>> >
>>>>> >
>>>>> >
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>