Hello Jose,
your proposal seems too specific to focused on addressing the problem you are solving and does not seem suitable for a
generic RESTful Java API.
Yet, the good news is that with JAX-RS 2.0 we plan to provide support for hyperlinking (maybe even redirects) as well as
asynchronous processing. The bad news is that you will still be required to actually do some Java coding as opposed to
your declarative annotation-based approach. :)
If you want to monitor our progress, the JAX-RS specification project page contain all the interesting pointers:
http://jax-rs-spec.java.net/
Also, for any JAX-RS related feedback, please feel free to use the JAX-RS users mailing list: users_at_jax-rs-spec.java.net
Kind regards,
Marek
On 08/16/2011 07:22 PM, Jose Antonio Illescas Del Olmo wrote:
> 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...
>>>>
>>>>
>>>
>>>
>>
>