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