On 6/29/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Stefan Tilkov wrote:
> > Apologies if this has been discussed before, but what's the status of
> > support for HEAD and OPTIONS?
> >
This is an excellent thread topic Stefan. I was just thinking about this the
other day in another context... =)
> > Intuitively, I think they should behave reasonably based on the
> > annotation metadata, but allow for overriding.
> >
>
> HEAD could be supported by the runtime calling the GET method and
> ignoring the returned entity.
Hmm at first blush this sounds like a good approach. But I worry that it
could be underperformant when we're talking about large resources. Do you
think clear documentation on the implications of not declaring a head()
method, when the get() is expensive, will suffice?
Otherwise Im totally with you Paul.
We allows nice reuse, but only if we allow for Response.Builder as a
> return type of an HTTP method.
That's not necessary:
@HttpMethod(HEAD)
Response head() {
return headInternal().build();
}
@HttpMethod(HEAD)
Response get() {
return headInternal().entity(en).build();
}
private Response.Builder headInternal() {
...
}
Same reuse is available without making the utility method a returnable type.
I think it's very important for the client method to invoke build() on the
builder and instantiate the object inside the http method (otherwise you
will play havoc with unit testing, metrics etc.). Ideally the impl
underneath should produce a Response object with all of its fields declared
final and safely published *before* it is returned from the client method.
Dhanji.