Pavel imagine the possibilities with annotated response headers (and
response status):
Custom redirects: using custom response status (and location header)
@Output( contentType="text/html", location="/any-url",
status="201") => Created (after POST/PUT)
@Output( contentType="text/html", location="/any-url",
status="301") => Moved Permanently
@Output( contentType="text/html", location="/any-url",
status="302") => Found (temporaily under different URL)
@Output( contentType="text/html", location="/any-url",
status="303") => See Other
Cache control: control caches with simple directives
@Output( contentType="*", cacheControl="no-cache", pragma="no-cache")
@Output( contentType="*", cacheControl="no-store")
@Output( contentType="*", cacheControl="max-age=300")
Queued process:
@Output( contentType="*", status=202) => Accepted (but no processed)
@Output( contentType="*", retryAfter=120) => any GET on non
processed resource (202-Accepted) can responds with: try again after 120
seconds (automatic reload of html pages)
I see this alternative as a JAX-RS feature => only configure your
response headers
<
http://en.wikipedia.oorg/wiki/List_of_HTTP_header_fields> with one
Annotation (Very Very simple)
Warnings: send warnings to clients: @Output( contentType="*",
warning="Some warning here...")
Language: set the response language: @Output( contentType="*",
contentLanguage="en")
Allows (methods): @Output( contentType="*", allow="GET, POST")
... (control any header)
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...
>>>
>>>
>>
>>
>