users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Request interface duplicates MBRs, HttpHeaders and UriInfo

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 14 Dec 2011 14:37:31 +0100

On Wed 14 Dec 2011 11:47:47 AM CET, 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;

HttpHeaders are incomplete in terms of type-safe support of request headers. However, they are too request specific to
be reusable in the response. Thus the new separate set of interfaces was designed with the intent to make HttpHeaders
deprecated (via javadoc wording) over time.

>
> 2. UriInfo offers all the methods needed to get to the current request/base/absolute uri, Request duplicates 5-8
> methods from UriInfo

I assume you are referring to something that's being already discussed in a different thread.

>
> 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.

No it doesn't. Request encapsulates the logic provided by handlers as well as mbr/mbw providers. In some cases it may
make sense to use request in other cases it doesn't. It's just a tool for a job. It's no different from any other
component in (any) API.

>
> For example, now instead of composite MBRs injecting Providers they will/should inject Request instead ?

Most certainly not. But obviously, it is a very broad question so a correct answer would be "It depends."...
Yet, I can only repeat that it is not our job to absolutely protect people from doing stupid things with the tools we
provide.

>
> 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

Consuming streams is already allowed by JAX-RS 1.x spec also in the resource methods. It is quite useful in fact if you
need to process large entities.

Marek

>
> Sergey