Polymorphic sub-resource locators (perfectly useful and legitimate in JAX/RS) are not handled by client proxy generators - likely because there isn't enough information in the standard JAX/RS annotations.

Consider this situation:

public interface Subresource
{
}

public interface SubresourceA extends Subresource
{
    @GET
    @Path("athings")
    @Produces("application/json")
    List<Integer> getAThings();

    // etc.
}

public interface SubresourceB extends Subresource
{
    @GET
    @Path("bthings")
    @Produces("application/json")
     List<String> getBThings();

    // etc.
}

@Path("/root")
public interface RootResource
{
     @Path("sub/{id}")
     Subresource getSub(@PathParam("id") String id);
}

In a client, if you are working with RootResource and know that the subresource with id = "Fred" is a SubresourceB, it would be nice if you could do something analogous to:

RootResource root = ...

SubresourceB b = (SubresourceB)root.get("Fred");
//... do stuff with b

The generated RootResource proxy has no way to know what type of Subresource is going to be returned. Only the user of the client interface (and the server implementation) has enough context to understand that the result of root.get("Fred") is going to be a SubresourceB.

Because this isn't covered in JAX/RS, how about an extension to the ResteasyClientProxy interface with this method:

   <T> T as(Class<T> iface);

With that addition, clients that are Resteasy aware could do this:

SubresourceB b = ((ResteasyClientProxy)root.get("Fred")).as(SubresourceB.class);

Additionally, suppose the ProxyBuilder ignores the method "as" with a single Class<?> parameter and no annotations, so interfaces could optionally declare:

public interface Subresource
{
   <T> T as(Class<T> iface);
}

Thus exposing the "as" method in the interface and allowing this:

SubresourceB b = root.get("Fred").as(SubresourceB.class);