Marc,
> Specifically for the case of HttpRequestContext, I see the following
> groups of methods:
>
> (i) Request URI information - getURIPath, getURIPathSegments,
> getURI,
> getBaseURI, getURIParameters and getQueryParameters
> (ii) Header information - getAcceptableMediaTypes, getCookies,
> getHttpHeaders, getMediaType (via getEntity) and getLanguage (via
> getEntity)
> (iii) Precondition support - evaluatePreconditions (3x)
>
> getHttpMethod and getContent (via getEntity) are both redundant in
> the case of an annotated method since their values are
> already either implicit (via @HttpMethod) or available as a parameter.
Agreed.
> For (ii) we already have @HeaderParam though there has been
> discussion about additional annotations for specific headers,
> e.g. an @Accept annotation could be used instead of
getAcceptableMediaTypes.
> I think I'm OK with this to a limited extent but I don't think we
> should have a separate annotation for every request HTTP
> header, that seems like overkill.
I don't think that @Accept corresponds to the "Accept" HTTP header here. The
"Accept" header list the media types accepted by the client, when the
@Accept annotation lists those acceptable by the server.
> Rather I'd prefer to only define separate
> annotations where they would be truly useful and have something
> generic to cover the others.
Agreed. We could split the HTTP headers into two sets, the lower-level ones
and the high-level ones. All of them would still be available via
@HttpHeader (or @WebHeader or better @Header).
> The metadata provided by Representation is a subset of the HTTP
> entity headers plus etag. The metadata provided by HttpResponse is a
> subset of the HTTP response headers plus the HTTP status code. It
> seemed logical to keep the two separate since they have different
> semantics: representation is all about the entity data, response is
> all about how that data is being used. The same
> Representation can be used in a variety of different responses,
> e.g. the same representation can be used in a 200 ok, a 201 create,
> a 307 temporary redirect, ... Having everything together in one class
> loses that separation but perhaps that is only important in my mind ?
Agreed.
Best regards,
Jerome