Hi Matthew,
In general the approach to having an XML enveloping mechanism that
embeds a response and includes error codes often implies a more RPC
oriented approach. HTTP already has status codes that indicate errors
for which the response entity can contain the information. You might
be able to define the terms of service as a separate resource. If you
are going to support JSON, RSS and ATOM the enveloping mechanism may
quickly break down.
However, if you need to provide some common functionality for common
"models" of representations then one can support this using Jersey
specific filters. For example the filter could look at the media type
and the entity and then do something extra with it e.g. for JAXB
beans it could wrap the bean around another bean, or another type
that is supported by a message body writer that performs the wrapping.
It is possible to support URI-based content negotiation as you describe.
I am sending this email from home on a different computer to the one
with all my information so when i get into the office i will send
another email with further details.
Paul.
On Jan 22, 2009, at 5:51 PM, Matthew Camuto wrote:
> Hi There -
>
> I am fairly new to jersey and have been loving what I see so far.
> However I have a few questions about about current needs at work.
>
> We are developing api's at work and have a few requirements that
> are desired. One that is that ever response would essentially be a
> 'template' if you will with some common information (think term of
> service, error codes). I realize that jersey is very 'pojo' and was
> not sure if this would be trivial to implment.
>
> For example we would want all of our api responses to look like
> something like this:
>
> <company>
> <tos> TERM OF SERVICE FOR ALL RESPONSES </tos>
> <error codes>
> Here would be error codes like 'param not found'
> <error codes>
> <response>
> ....// concrete data here based on java object type....
> </response>
> </company>
>
> So in essence I am looking to capture the response from an endpoint
> and wrap the data in my generic xml format. And I would like to
> centralize the generic stuff like error handling and have the
> ability to give the user a verbose message about the error they can
> easily consume (i.e. 'start date should be before end date'...) I
> am not sure if this would be trivial in jersey without having a lot
> of repetition in each of my methods. I am also supposed to support
> json,rss,atom so I am trying to keep all the 'plumbing' to a
> minimum.. I am not sure if this flies in the face of jax-rs or not?!?!
>
> Also. I did not see this in the docs? Is it possible to specify
> return type in thu uri params. i.e. default to xml always but if
> you had...
>
> //myurl/service?format=atom
>
> have it auto detect the return type.
>
> Thanks in advance.
>
> matt