Re: JSR311: Client API

From: Bill Burke <>
Date: Mon, 10 Mar 2008 11:51:19 -0400

Ryan McDonough wrote:
> Stefan,
> I think I was the one who may have kicked off this thread originally,
> but I now share similar feelings as you. After thinking about for a few
> months, here's some of my thoughts as to why a uniform interface may not
> work:
> * If the resource can be represented by multiple types, how does the
> client select the preferred type?

You mean with the proxy framework I did? You reuse the @ProduceMime
annotation to specify the accept header. In this case @ProduceMime
means, please produce that type for me. Accept headers are generated
from @ProduceMime annotation.

interface ClientProxy {

    @ProduceMime({"text/html", "text/*"})
    public String get();

GET /resource
Accept: text/html, text/*

> * Similarly, when a resource is created and a 201 response is
> returned and the response contains multiple choices, how is a
> defaul type selected?

201 == created. Not sure what use case you mean here by "multiple
choices". You mean @Location headers? One idea I had was that a @GET
call could return a proxy class

public interface Factory {

SomeResource create();

create() returns a new client proxy to whatever Location header exists
in the response.

If you don't mean Location headers, then there's no reason the client
can't specify @ProduceMime (accept headers) it wants for a response.

> * Building on the last point, if such a client API automatically
> selected a preferred type, is redirecting the client to the new
> location the behavior the caller is expecting? Granted in most
> cases it would be, but sometimes it may not be.

In this case, make the method return void. Void means, I don't want a

> Granted these are not insurmountable issues to resolve, but I'm starting
> to think that perhaps a client API should appear in JAX-RS 1.x or 2.0.
> In that time, I'm sure multiple JAX-RS implementations will have
> experimented with various client implementation and we can collectively
> learn from those experiences.

I'm fine with that, I didn't think it would make it in. BUT, I don't
want anything in the spec from hindering this. So far there isn't any
barrier to reusing annotations/APIs/SPIs though.

Bill Burke
JBoss, a division of Red Hat