Jerome Louvel wrote:
> Considering the initial scope of the JSR and the fact that the EG is already
> behind schedule, I don't think it is reasonable to pursue such an effort for
> now.
>
Makes sense. I agree with Marc that it could be something to consider
for another revision rather than for this revision.
> What surprises me is that the client-side API proposed has nothing to do
> with annotations and don't even seem to reuse any artifact from the current
> API.
>
The following classes are used:
javax.ws.rs.core.Context
javax.ws.rs.core.EntityTag
javax.ws.rs.core.MediaType
javax.ws.rs.core.MultivaluedMap
javax.ws.rs.ext.MessageBodyWriter
javax.ws.rs.ext.MessageBodyReader
javax.ws.rs.ext.RuntimeDelegate
javax.ws.rs.ext.RuntimeDelegate.HeaderDelegate
javax.ws.rs.core.UriBuilder
From a design perspective it:
- follows the same ease of use pattern for building requests as on the
server side for build responses; and
- uses the message body readers/writers with injectable configuration as
can be done on the server side.
The main focus of the API is the uniform interface (it can be considered
a very simple wrapper over say HttpURLConnection or the Apache HTTP
client). I wanted to avoid the reliance on any specific code artifacts
specifying, or partially specifying, a service that introduces static
dependencies in code thereby increasing the coupling between client and
server. From the way i approached the problem it did not make any sense
to reuse the annotations for the client side.
I also want a (pre-configured) client-side artifact i could inject and
reuse on the server-side, like as follows (without having to create or
depend on any server-specific code artifacts):
@Path("/")
public class Foo {
@WebResourceRef("
http://host/path") WebResource r;
@GET public String get() {
return r.get(String.class);
}
}
Paul.
> What is the point? If we have to do something within JAX-RS (now or later),
> it would make much more sense to follow the approach proposed by Bill.
>
> Best regards,
> Jerome Louvel
> --
> Noelios Consulting
> http://www.noelios.com
>
>> -----Message d'origine-----
>> De : Bill Burke [mailto:bburke_at_redhat.com]
>> Envoyé : mercredi 5 mars 2008 21:09
>> À : dev_at_jsr311.dev.java.net
>> Objet : Re: JSR311: Client API
>>
>>
>>
>> Marc Hadley wrote:
>>> Issue 22[1] raises the question about whether we should
>> define a client
>>> API as part of JAX-RS. Back in October[2] we tabled
>> discussion until
>>> we'd made some progress on a client API we were developing
>> for testing
>>> purposes. Paul recently blogged about the resulting API
>> that has been
>>> developed in Jersey[3] and I'd like to revive the
>> discussion on issue 22
>>> now we have something concrete to propose. For reference I've also
>>> uploaded the javadoc[4] to the jsr311 project.
>>>
>>> The API is implemented in Jersey trunk and will be included
>> in Friday's
>>> release of the 0.6 snapshot. I'd recommend getting a copy
>> and playing
>>> with the classes a little to get a feel for how things slot
>> together.
>>> Paul will follow up tomorrow with some additional worked examples.
>>>
>>> Note that a client API was not one of our original
>> deliverables and is
>>> only being discussed in light of requests from EG members. It would
>>> still be an acceptable outcome (for me at least) to defer
>> inclusion of a
>>> client API to a subsequent revision of the specification.
>>>
>> I'm happy with Apache HttpClient and use it to test our jax-rs
>> implementation. Its a little clunkier than what you're
>> proposing, but a
>> bit more mature and much more feature rich.
>>
>>
>> For a client API I was thinking more of:
>>
>> http://wiki.jboss.org/wiki/Wiki.jsp?page=RESTeasyClientFramework
>>
>> Where you could re-use jax-rs annotations and providers on an
>> interface
>> to create a proxy. What we have implemented still needs some
>> work, but
>> you probably get the gist.
>>
>> Bill
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109