We thought I that, but ultimately we got it working by registering subtypes with Jackson and choosing the right one. Seems to work fine :)
thanks
sam
On Thursday, May 17, 2012 at 4:44 PM, Tatu Saloranta wrote:
> On Thu, May 17, 2012 at 12:55 PM, <sam_at_permans.com> wrote:
> > Hello
> >
> > We have a resource that might be one of a couple different subtypes.
> > We've been trying to use variations on Content-Type to identify which
> > subtype is in play. For example, on the server we might have
> >
> > public interface Foo {}
> > public class FooA implements Foo {}
> > public class FooB implements Foo {}
> >
> > And then a couple different content types like so:
> >
> > application/x.foo+json; type=a
> > application/x.foo+json; type=b
> >
> > This has been working great with GET requests. We can set the outgoing
> > content type as we see fit. We're really struggling with POST requests
> > though. If we define our resource with the following methods then
> > jersey says they conflict:
> >
> > @POST
> > @Consumes("application/x.foo+json; type=a")
> > public Response create(FooA entity) {}
> >
> > @POST
> > @Consumes("application/x.foo+json; type=b")
> > public Response create(FooB entity) {}
> >
> > So I guess I have two questions.
> >
> > 1) Is it possible to delegate like this using parameters on the content
> > type?
> > 2) If not, is it possible for our application to choose the type
> > (either FooA or FooB to read the json into?)
> >
>
>
> Have you considered instead of using Jackson's polymorphic type
> handling to take care of this?
> That works without trying to use content/media types; just tack
> @JsonTypeInfo on common base class, and it'll add type info to bring
> proper sub-type back.
>
> -+ Tatu +-