On 14/12/11 10:47, Sergey Beryozkin wrote:
> Hi
>
> I've had a closer look at the updated Request interface and IMHO it's
> grown into a uber-interface that exposes much of the imformation which
> is already available in other interfaces which can be injected into the
> application code and also exposes the methods that the application code
> should not even see.
>
> 1. HttpHeaders is there to provide the info about the current headers;
> Request offers RequestHeaders which mainly duplicates what HttpHeaders
> can offer; would it make sense to get Request updated to return
> HttpHeaders instead and may be just drop RequestHeaders;
>
> 2. UriInfo offers all the methods needed to get to the current
> request/base/absolute uri, Request duplicates 5-8 methods from UriInfo
>
> 3. JAX-RS is about MessageBodyReaders making it possible for users to
> write the code like this:
>
> public void post(Book book);
>
> Having Request all of those methods that users are supposedly can/should
> (?) call instead does not make sense to me. Request takes upon the MBR
> and in fact the Providers functionality here.
>
> For example, now instead of composite MBRs injecting Providers they
> will/should inject Request instead ?
>
> I know that filters do need such methods - hence I propose to move these
> input stream/etc getters away from Request and make them visible on
> relevant filter/handler interfaces
These input stream/data getters make more sense on Response, especially
when we have a client side dealing with it,
>
> Sergey