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
Content-Type.
(I don't have access to my source code at the moment... ;))
But it must be something like "return
Response.ok(myInputStreamOrEntity).type("application/pdf").build();"
I this cases my URLs end with the name of File, so the clien is expecting
"PDF" if it the URL ends with.
Bye,
Daniel
2011/4/12 <lists_at_zimmer428.net>
> 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