Far from me the idea of suggesting that this framework is better than the
other, as they all have their merits and are good in the specific cases for
they were build for.
That being said, your use case seems a strong candidate to be used by
Spring Integration, as you can have your "normal logic" of
getting "concrete data based on java object type" and just wrap it in the
endpoints with Message Transformers.
Or, as is my actual case, use Jersey for the connectors/resources side and
Spring Integration handling the Messaging to and from the server "service
implementations" including the transformations and wrapping and etc...
Hope it help.
On Jan 22, 2009 4:51pm, Matthew Camuto <mattcamuto_at_gmail.com> 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:
>
>
> TERM OF SERVICE FOR ALL RESPONSES
>
> Here would be error codes like 'param not found'
>
>
>
> ....// concrete data here based on java object type....
>
>
>
> 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 (ie '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. ie default to xml always but if you had...
>
> //myurl/service?format=atom
>
> have it auto detect the return type.
>
>
> Thanks in advance.
>
> matt
>