Pl. see below.
________________________________
From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
To: Sastry Malladi <m_sastry_at_yahoo.com>
Cc: "jsr339-experts_at_jax-rs-spec.java.net" <jsr339-experts_at_jax-rs-spec.java.net>
Sent: Monday, December 12, 2011 9:17 AM
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: New to the group - comments on the current draft
On Dec 9, 2011, at 4:36 PM, Sastry Malladi wrote:
>
>
>
>
>________________________________
> From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
>To: Sastry Malladi <m_sastry_at_yahoo.com>
>Cc: "jsr339-experts_at_jax-rs-spec.java.net" <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 :)
Sastry > If we are going to try to keep the interface the same, then "entity filters" may be better, but otherwise, "entity handlers" seems good.
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.
Sastry> OK
>
>* 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.
Sastry > I was thinking something simple like what the Jayway folks have implemented, where a template class is specified on the resource method's Linkable annotation and the jax-rs container returns the HTTP method name and the fields in the template class, including any validation contraints (e.g NotNull) etc.
-- Santiago