Sorry, one more time reply to you and not to list....
I listen to you, and I undestood your point-of-view...
· I really know container/resource filters (Pavel send me on previous
post)
· I expect the inclusion of interceptors/filters on 2.0 version
(JAX-RS providers use custom solutions and migrations form one to
another is not simple)
Marek, Thank you for your time
On 18/08/2011 12:23, Marek Potociar wrote:
>
> On 08/18/2011 12:10 PM, Jose Antonio Illescas Del Olmo wrote:
>> Marek,
>>
>> It's true that my solution addressed many topics: one for every allowed response header.
>>
>> But initially I don't like create multiple annotations (each for every header): @Redirect, @Expires, @Allows...
>> (complicated to remember)
> I understand your aversion towards annotation proliferation, but IMHO this may be just one of the signs, that
> annotations are simply not the right strategy to solve this problem.
>
>> It's true that many response headers are not static: Date, Cookies, Last-Modified...
> Another point against annotations.
>
>> I don't known if someone require distinct response headers for distinct content-types (HTTP don't restrict this)
>>
>> On your example: response depends on contentType (not on id) => text/html: returns 301 + url; other content types
>> returns 200 + entity
>>
>> Of course, I can set headers to any content type
>>
>> @Path("{id}")
>> @GET
>> @Output(location="/any-url", status="301") => similar to: @Output(contetntType="*", location="/any-url", status="301")
>> public String getById(@PathParam("id") String id) {...}
>>
>>
>> Now the service reacts similar to any contentType or I can remove the contentType from @Output annotation to restrict
>> headers to all contentTypes (and not allows @Outputs with many @Output)
>>
>> please, see this as an idea on evolution...
> You don't seem to listen. I am trying to tell you that, in my opinion, you are on the wrong track with your idea. I am
> sorry. It would be OK if you requested some extension of the programmatic API to make it less verbose with most commmon
> use cases and I hear your point in that respect. It's however a mistake to tie such request with the annotation-based
> solution.
>
> Cheers,
> Marek
>
>>
>> Thank you
>>
>>
>> On 18/08/2011 11:39, Marek Potociar wrote:
>>> 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...