It seems quite specific to your problem... in my opinion, it does not add value to a framework that's supposed to be generic enough for building REST infrastructure...
IMHO
Date: Wed, 17 Aug 2011 10:34:33 +0200
From: jantonio.illescas_at_rbcdexia-is.es
To: users_at_jersey.java.net
CC: skyscrapper666_at_hotmail.com
Subject: [Jersey] Re: dinamyc content type
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:
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)
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
static: redirect to static configured URL
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...