Ok, let me repeat myself (the response I sent you yesterday):
You seem to combine too many different topics (redirection, asynchrony, request processing etc.) into a single concept
to solve your specific problem. IMHO that goes against the recognized OOD principles and best practices, such as
low-coupling, high cohesion or interface segregation. For more info see e.g.:
http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29
http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
To demonstrate the problem, let's just consider one example of your annotation:
@Output( contentType="text/html", location="/any-url", status="301") => Moved Permanently
How would I use this annotation on a typical JAX-RS HTTP resource method like this:
@Path("{id}")
@GET
public String getById(@PathParam("id") String id) {...}
if the method returns HTTP 200 + response entity for some "id" values and HTTP 301 for some other "id" values?
Cheers,
Marek
On 08/18/2011 11:37 AM, Jose Antonio Illescas Del Olmo wrote:
> 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...
>>>>>>
>>>>>
>