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)
It's true that many response headers are not static: Date, Cookies,
Last-Modified...
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...
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...