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.
@Path("/resource")
interface ClientProxy {
@GET
@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
@Path("/factory")
public interface Factory {
@PUT
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
response.
> 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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com