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.
> * The scenario that is not covered is handlers for wrapping around resource method invocation - This is needed, for example, to measure the time taken by the resource method itself (monitoring/metrics).
You can use CDI (or EJB) interceptors for that.
> * Binding : The binding methods described are flexible, but in reality, only GlobalBinding is what is used in an operational environment.
I don't agree with that.
> However, specific resources may indicate that certain filters don't apply to them - For example a SecurityFilter is always globally configured in an environment and some resource may specifically say, they want to turn security off, since they are not secure resources.
Yes, I think this is a use case that isn't covered --at least not declaratively. If you want, file a JIRA to track this use case.
> Have you considered declaring all such filters/handlers in a config file at the container level, but individual resources either add or override certain filters via a Config init parameter or such ? Usability and practicality is very important to consider here.
No, we haven't considered that yet. Note that running on servlet container (for example) is not a requirement in JAX-RS.
> * Binding : Why is it different on the client and server side ? Can we not use the same approach on both sides ?
Name binding is different because there's no place for the annotations on the client side. Also, as there's typically no class scanning on the client, providers need to be explicitly registered on either Client, Target or Invocation.Builder.
> Hypermedia support
> This is an important topic dear to my heart and to me hypermedia support should include
That's good!
> * Ability for the resource developers to specify which fields in their entities correspond to a resource (or sub resource), so that the container will automatically insert a link - whether for the self resource or some other resource.
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).
> * 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?
> * Ability for the resource developers to specify that the media representation be converted into HTML (so user friendly rendering can happen)
Via a template? That would be more MVC that hypermedia.
> * Now coming back to where the links should be : I think that they can both be in headers (Link header) as well as in the payload under a special reserved field called "links"
This would require the app's DTO to have the entry for the links and the framework to introspect it. As I said above, this goes beyond a simple programmatic API. Instead, I think for this version, we'll allow programmers to use Link in their DTOs and let them do that by hand, but help them with the link generation --thus, not forcing any particular type of DTO, etc.
-- Santiago