On Apr 13, 2007, at 10:33 AM, Dhanji R. Prasanna wrote:
>
> On 4/14/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> I agree that most things in there could be injected as method
> parameters but to do so separately would require 10 new annotations
> (assuming all the request data obtainable remains desirable). Perhaps
> we should consider a somewhat coarser granularity, e.g. we could have
> an injectable UriInfo interface that contains the HttpRequestContext
> methods associated with the request URI rather than injecting each
> part of the information separately.
>
> Im open to this, but I dont see a problem with several annotations.
> You choose the ones you need and ignore the rest; whereas with all-
> purpose interfaces you are forced to understand the semantics of
> the entire object (and its roles) or risk uninformed use.
>
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.
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. Rather I'd prefer to only define separate
annotations where they would be truly useful and have something
generic to cover the others.
> > Or why Representation<T> doesnt encapsulate metadata returned in
> > the response. Is this the 20/80 facilitator? If so I'd worry about
> > later.
> >
> I don't understand that comment, Representation<T> does encapsulate
> metadata returned in the response: content type, content language,
> content location, last modified and etag.
>
> Sorry, that was a bit of a run-on. I meant that I believe
> Representation<T> fulfills the metadata requirement and that I do
> not see the need for additional artifacts (such as HttpResponse and
> HttpResponseContext) to serve the same purpose.
>
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 ?
Marc
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s