On Jan 23, 2009, at 11:15 AM, Paul Sandoz wrote:
> 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.
>
For details on filters see the following email thread:
http://markmail.org/search/?q=list
%3Anet.java.dev.jersey.users#query:list%3Anet.java.dev.jersey.users
+page:1+mid:pls2t443eva3yxfb+state:results
Note that reource specific filters are implement in 1.0.2-SNAPSHOT
where as container specific filters are implemented in 1.0 and 1.0.1.
For URI-based conneg you currently need to do the following:
http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+getMediaTypeMappings#query
:list%3Anet.java.dev.jersey.users%20getMediaTypeMappings+page:1+mid:jmh6vnv3pr45oeot+state:results
See ResourceConfig [1] and ServletContainer [2] on how to register a
ResourceConfig implementation.
If anyone requires this to be easier for servler configuration e.g.
via a init-param let me know and/or log an issue.
Paul.
[1]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/com/sun/jersey/api/core/ResourceConfig.html
[2]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.1/api/jersey/com/sun/jersey/spi/container/servlet/ServletContainer.html
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>