On Jun 29, 2007, at 7:40 AM, Dhanji R. Prasanna wrote:
>
> 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?
>
Sounds good to me. So, for a HEAD request (in order or decreasing
preference):
1. Call a method annotated with @HttpMethod(HEAD) or, if none present,
2. Call a method annotated with @HttpMethod(GET) and discard any entity.
I agree we should flag the potential for decreased performance with 2.
For an OPTIONS request:
1. Call a method annotated with @HttpMethod(OPTIONS) or, if none
present,
2. Automagically generate a response from the declared metadata
> We allows nice reuse, but only if we allow for Response.Builder as a
> return type of an HTTP method.
>
I'd prefer to keep Response.Builder out of the contract for a
resource method if possible.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.