On 12/12/2011 06:17 PM, Santiago Pericas-Geertsen wrote:
>
> On Dec 9, 2011, at 4:36 PM, Sastry Malladi wrote:
>
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------
>> *From:* Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com <mailto:Santiago.PericasGeertsen_at_oracle.com>>
>> *To:* Sastry Malladi <m_sastry_at_yahoo.com <mailto:m_sastry_at_yahoo.com>>
>> *Cc:* "jsr339-experts_at_jax-rs-spec.java.net <mailto:jsr339-experts_at_jax-rs-spec.java.net>"
>> <jsr339-experts_at_jax-rs-spec.java.net <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
>> *Sent:* Friday, December 9, 2011 6:54 AM
>> *Subject:* [jsr339-experts] Re: [jax-rs-spec users] New to the group - comments on the current draft
>>
>> Hi Sastry,
>>
>>> * As I understand it, Handlers don't seem really generic handlers, but specifically "filters" for Entity
>>> Providers, if you will. But they are also providers. It is confusing.
>>
>> The term "provider" is used for any type of framework extension (aspect) in JAX-RS. So you have entity providers,
>> filter providers, etc. Filtering and entity processing are really separate aspects. Have a look at the attached diagram.
>>
>> Sastry > Thanks for the diagram - I understand the difference, was commenting on the completeness as well as the
>> naming. Please refer to my reply on the other thread.
>
> Handlers were called interceptors at first, which was also confusing. We are still trying to find a better name for
> them. Something with the word "entity" would help. Not sure about "entity filters", somehow I like "entity handlers"
> better :)
I would not confuse wrapping and non-wrapping under same name. Let's keep "filter" reserved for non-wrapping stuff. I am
fine with Handler, EntityHandler, EntityInterceptor ...
Marek
>
>> We considered cases like that (see Jersey documentation for example), but it's hard to get agreement on how much
>> poking around we want the framework to do. I think it's important to proceed gingerly here and add more behavior as we
>> gain more experience. The current plan is to focus on a programmatic solution (i.e., give the tools to the app
>> developer to do what he/she needs).
>>
>> Sastry > I think it is ok to just give the programmatic interface (without the framework poking around the entities),
>> however, it will be good to insert these links in the returned data, without the user having to explicitly declare the
>> link fields in their entities. What do you think about that ?
>
> That's what I meant by poking around :) I'm hesitant to impose this type of processing requirements on all JAX-RS
> implementations. There's also the issue of message body readers/writers handling these type of extended entities. I
> think we should add some methods to help on the generation of links (and a Link type) and push this for the next JAX-RS
> version. I'm positive that JAX-RS implementations will innovate in this area and we can use that in the future.
>
>>
>>> * Ability for the resource developer to specify to optionally include any meta data for how to change the
>>> representations - For example, if you have a purchase order resource, and in order to update the purchase order one
>>> must supply certain parameters or can only update certain fields, but not the others etc. This is important in the
>>> REST world, since there is no schema for the resource interface.
>>
>> No sure I follow this. Could you do it with custom validators?
>>
>> Sastry > What I meant is that, similar to how we are talking about returning the "links" for either self or embedded
>> resources/sub-resources, returning some "metadata" like POST templates or PUT templates, so that the caller, once he
>> does a GET, he/she also knows how to update/create that resource, if they need to etc. The resource developer can
>> specify this using an annotation, when desired. I think this will be very useful to the consumers.
>
> You mean something like WADL? Agreeing on the right "description language" would take another EG! Somewhat unfortunate,
> perhaps, this is not in the scope for JAX-RS 2.0.
>
> -- Santiago
>