Menu
▾
▴
Re: [Resteasy-developers] ClientProxy addition: "public Response someMethod()"
|
From: Bill B. <bb...@re...> - 2008-12-29 13:38:19
|
Or, we could just extend Response:
public class ClientResponse extends Response
{
abstract <T> T getEntity(Class<T> type);
abstract <T> T getEntity(Class<T> type, Type genericType);
abstract <T> T getEntity(GenericType<T> type);
}
And client code would look like this:
ClientResponse response =
(ClientResponse)proxy.methodThatReturnsAResponse(...);
MyType obj = response.getEntity(type);
Maybe we still want the annotation too?
Solomon Duskis wrote:
> There would be a corresponding EntityTypeFactory interface that would
> enforce the "take in the status and headers and return a class"
> requirement...
>
> Something like
>
> @ClientResponseType(typeFactory=SomethingTypeFactory.class)
> ...
>
> public class SomethingTypeFactory implements EntityTypeFactory
> {
> public Class getEntityType(MultivaluedMap<String, String> headers, int
> status)
> {
> if( status == 200 ) return Something.class
> ...
> }
> }
>
> -Solomon
> On Mon, Dec 29, 2008 at 7:23 AM, Solomon Duskis <sd...@gm...
> <mailto:sd...@gm...>> wrote:
>
> Ultimately, having a single interface for the client and server are
> useful if you control both ends of the communication. I'm going to
> push a bit more on this topic, because we found some annoying issues
> when we started moving towards Response on the server.
>
> IMHO, most of the time @ClientResponseType with entityClass (with an
> optional generic type would work). However, I would happilly add a
> typeFactory property that would take in the status and headers and
> return a class.
>
> What do you think?
>
> -Solomon
>
> On Sun, Dec 28, 2008 at 11:33 PM, Bill Burke <bb...@re...
> <mailto:bb...@re...>> wrote:
>
> There's also the problem of errors. An error message might be a
> different content type than the expected entity.
>
> Solomon Duskis wrote:
>
> I do understand that. Would it be ok to introduce an
> annotation that defines how a client can interpret the body
> of a response into an object?
>
> Something like ClientResponseType:
>
> @GET @Produces(...)
> @ClientResponseType(entityClass=Something.class)
> @Path("/something/{id}")
> Response getSomething(@PathParam("id") Integer id);
>
> -Solomon
>
> On Sat, Dec 27, 2008 at 4:23 PM, Bill Burke
> <bb...@re... <mailto:bb...@re...>
> <mailto:bb...@re... <mailto:bb...@re...>>> wrote:
>
> There's no API to pass in type information to a Response
> object so
> it knows how to unmarshal the entity. That's why
> ClientResponse exists.
>
> Solomon Duskis wrote:
>
> We have cases where we'd like to customize the
> Response on the
> server, but would like to keep the same Java
> interface for both
> the client and the server. For example:
>
> @PUT @POST
> @Consumes("foo/bar")
> @Path("/something")
> @Path Response putSomething(Something something);
>
> In this PUT/POST case, I'd like to return a CREATED
> status and a
> Content-Location to the url for the new Something.
> Right now,
> you have to have a different Java interface for the
> client and
> the server. I'd like to not have to use a
> ClientResponse on the
> client, rather, I'd like to just use the same
> interface with
> Response signature on both client and server. It's
> pretty
> straight forward to convert a ClientResponse's
> headers and
> status into a Response.
>
> A GET is a bit trickier:
>
> @GET
> @Produces("foo/bar")
> @Path("/something/{id}")
> Response getSomething(Integer id);
>
> I'd like to return NO_CONTENT if the id doesn't
> return any data,
> and if there is data for that id return a 200 and the
> Something
> object. In this case, if the client does return
> data, The
> client needs enough information to convert the data
> that's
> coming from the server into a Java object
> representation. I can
> think of two ways to do that:
>
> 1) an annotation, something like
> @ResponseType(entityClass=Something.class)
> 2) http headers. This case is really only useful if
> RESTEasy
> owns both ends, so we can put a User-Agent of
> "RESTEasy Client"
> on a request, and put some custom HTTP headers for
> entity class
> and generic type on the response.
>
> There may be other solutions, but I did get both
> options working
> without much trouble.
> What do you think?
>
> -Solomon
>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> <mailto:Res...@li...>
> <mailto:Res...@li...
> <mailto:Res...@li...>>
>
>
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
> -- Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|