Yes, must be processed as any HTTP request.
Exist Content-type-negotiation (CTN) based on "Accept" request
header and "contentTypes" configured on service (with @Produces or @Output).
I really see 2 posibilities based on JAX-RS API:
1.- Servlet filter that captures any request and sets the response
headers (and status) from selected @Option.
· Guice based interceptor captures any method annotated with
@Option and store options on ThreadLocal
· Servlet filter select the apropiated @Option based on
HTTPServletResponse.status => use HTTPServletResponseWrapper to
retrieve the status code.
2.- Guice interceptor captures any method annotated with @Option and
generate custom "javax.ws.rs.core.Reponse" based on selected @Option
note: this solution require program content-type-negotiation
algorithm (not use Jersey CTN) to select the apropiated content type.
Please, note that:
· first alternative use content-type-negotiation provided by JAX-RS
implementation (Jersey) based on "Accept" request header and @Provides
annotation
· second one require custom content-type-negotiation (JAX-RS hide to
developer) based on "Accept" request header and @Provides/_at_Option
annotation (use @Option when present and @Provides in other case)
On 17/08/2011 04:25, Rob - wrote:
> Shouldn't that be driven by the HTTP Accept header and processed as
> any http request?
>
> ------------------------------------------------------------------------
>
> On 16/08/2011 18:31, Jose Antonio Illescas Del Olmo wrote:
>
> Paul, apologize for any inconvenience on my expressions (English
> is not my native language).
>
> Sorry...
>
>
> Let me explain my idea: now, my rest framework works:
>
> 1. Request -> Java -> XML (with XStream) -> Transformation
> (XSL/STX) -> Response => Yes, internally only works with
> XML and transform with XSL/STX to any format (at moment any
> object can output as: XHTML, JSON, CSV or PDF)
> 2. Any Request can controlled (MVC point of view) as:
>
> * Transformation: any GET request generates a Java response
> that "serialize" Objects to XML and "transformed" with XSL/STX
> * Redirect: any POST, PUT, DELETE request redirect to some
> (static or dynamic) url after process
> o static: redirect to static configured URL
> o dynamic: redirect to programatic generated URL
> * Error: any error redirect to previous URL (form with submit
> button) with current parameters (filling any input with
> submited values) and a new one "error" with a message error
> (showing the error at top)
>
> Well, on JAX-RS any custom Response requires programatic actions.
> But... Can exits any "static" (annotated alternative)?
>
> My idea is annotate services with "static" headers (and
> response codes) per mediaType:
>
> @GET
> @Output { contentType="text/html", link="html.xsl" } => custom
> provider serialize result object to XML and transforms with
> "html.xsl" when contentType = text/html
> public Object find(...)
>
>
> @PUT
> @Output { contentType="*", location="/some-resource-url" } =>
> redirect to "/some-resource-url" after processing to any Request
> public Object post(...)
>
> @POST
> @Output { contentType="*", status = 202 } => responds with 202
> - Accepted but not processed to any Request
> public Object acceptedButNotPrecessed(...)
>
> Of course, I say per media type, you can annotated multiples
> mediatypes:
>
> @GET
> @Outputs {
> @Output { contentType="text/html", link="html.xsl" } , =>
> custom provider serialize result object to XML and transforms with
> "html.xsl"
> @Output { contentType="application/json", link="json.xsl" }
> , => custom provider serialize result object to XML and transforms
> to html with "html.xsl"
> @Output { contentType="text/csv", link="csv.xsl" } , =>
> custom provider serialize result object to XML and transforms to
> json with "json.xsl"
> @Output { contentType="application/pdf", link="xsl-fo.xsl" }
> , => custom provider serialize result object to XML and transforms
> to xsl-fo with "xsl-fo.xsl"
> }
> public Object find(...)
>
> @Output annotation allows "simple alternatives" without programming.
>
> Your opinion?
>
>
>
> On 16/08/2011 17:30, Pavel Bucek wrote:
>
> well, you have your "ugly" solution. Currently I don't see the
> way how you could obtain result of content negotiation process
> (I think this was here some time back and result was basically
> the same).
>
> Btw, how many content types (approx) are you supporting per
> resource?
>
> On 8/16/11 5:12 PM, Jose Antonio Illescas Del Olmo wrote:
>
> Please any suggestion?
>
> I needed the "default contentType" after jersey
> content-type-negotiation? (I need on my REST method,
> annotated with @POST, @PUT)
>
>
> On 11/08/2011 16:04, Jose Antonio Illescas Del Olmo wrote:
>
> Can get the "default" contentType selected by Jersey
> on my method?
>
> Please note that Jersey (and any JAX-RS
> implementation) calculates the content type to invoke
> the method with valid media type...
>
>
>
>
>
>
>