[Jersey] Re: dynamic representations?

From: Daniel Manzke <>
Date: Tue, 12 Apr 2011 11:30:24 +0200

Should be pretty simple. Don't use the @Produces. You only need the
annotation, if the client sends the right headers, so Jersey can evaluate,
if the client is expecting/understanding the right format.
You use your normal URLs and determine the Mime-Type for your Content at
Runtime. Your method than returns a Response-Object, where you can set the

(I don't have access to my source code at the moment... ;))

But it must be something like "return

I this cases my URLs end with the name of File, so the clien is expecting
"PDF" if it the URL ends with.


2011/4/12 <>

> Folks;
> in our setup, I do have resources which are available in various
> representations, but generally, there is no real way of telling which
> representations those are. In some situations, there might be PDF and
> HTML files, in others, there might be JPG and SVG, and so forth, and in
> general, the very idea of the solution is to be as extensible and
> "dynamic" as possible.
> For what I have seen so far, most of what makes Jersey / JAX-RS neat is
> the option to provide a @Produces annotation declaring what kind of
> content is returned by a given method. Which, however, gets me in
> trouble right now: For our stored entities, there is the concept of a
> "primary binary representation", which is HTML or PDF or JPG or
> whatever, and the customer / client to store the entity determines
> which document this "primary representation" will be.
> In the end, I was about to build an URI just alike
> http://.../entities/{id}/primaryRef to provide access to this primary
> representation. But: How to deal with the fact that ultimately this URI
> might end up in a load of different representations entirely depending
> upon the very entity requested? First thought was to declare something
> akin to @Produces("application/octet-stream") and avoid dealing with
> this issue altogether, but this doesn't seem to smart from a client
> side point of view. Are there more sane ways of dealing with this? How
> do you, conceptually, handle use cases like this in your apps? Is my
> design, after all, a bad decision from looking at representations and
> URIs?
> Thanks for any thoughts / pointers / inspirations on that...
> Kristian

Viele Grüße/Best Regards
Daniel Manzke