jaxzin wrote:
> So I'd like my resources to support path suffixes like '.xml' and '.json' to
> make is simpler for users to choose their response format without needing to
> set the Accept header properly. Is there anything similar built into
> Jersey such as a query param it looks for or something? I'm willing to go
> with an turn-key solution even if its differs from my path suffix idea. Any
> other good ideas? I'd like to do it transparently without changes to my
> resource classes such as accomplishing it with a Provider implementation or
> some other configuration setting.
>
I would probably look at implementing a Jersey ContainerRequestFilter,
returning a modified ContainerRequest that adjusted the path to remove
the suffix, and add an appropriate "Accept" header. Because this all
happens before the request is mapped to an actual resource method,
Jersey will take care of the rest of the problem for you, and you can
use the usual approach of a @Produces annotation on your resource method
to select the appropriate response, so you don't have to pollute every
resource method in your application with a kludge to support this.
Google "Jersey ContainerRequestFilter" for some blogs and mailing list
threads on this topic.
> Thanks,
> Brian
>
> P.S. Another 'real world' reason I need to skip out on the Accept header is
> that our page caching solution is know to have trouble with caching properly
> when requests to the same URL differ by the Accept header. (In case anyone
> was ready to reply "Don't do that") :-)
>
Sounds like a good argument to scrap a caching solution that doesn't
understand how HTTP actually works :-).
Craig