users@jersey.java.net

[Jersey] Re: dinamyc content type

From: Jose Antonio Illescas Del Olmo <jantonio.illescas_at_rbcdexia-is.es>
Date: Thu, 18 Aug 2011 11:37:34 +0200

Sorry, yesterday reponds your email without redirect to jersey list

    Can you explain me why you don't see this solution generic? (please
see my today post to Rob on this list with some examples)


I really interested to known your point-of-view and known why you see it
as generic solution.

Regards



On 17/08/2011 17:53, Marek Potociar wrote:
> 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...
>>>>>
>>>>