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...
>