OK, I'll add a method:
String Request.getMethod()
and explicitly disallow multiple method designators on a single
resource method.
Marc.
On Jun 2, 2008, at 12:10 PM, Stephan Koops wrote:
> Hi, Betold,
>>> The API allows programmatic access to almost anything in the
>>> request except the HTTP method. It is possible to annotate methods
>>> with HttpMethod or any of the pre-defined method designators, but
>>> I don't see how the HTTP method name can be obtained via the API.
>>>
>> The only way to do that currently is to inject an instance of
>> HttpServletRequest and get the method from there. This will only
>> work inside a servlet container.
>>> I would like to put some authorization call inside resource
>>> methods in some generic way. Instead of hard-wiring the name or
>>> doing my own mapping (e.g. POST - create, GET - read, etc.), it'd
>>> be nice if the method name were also available.
> IMO this is a good point. I propose to add Request.getMethod() :
> String or Request.getHttpMethod() : String.
>>> From reading 3.1, it is entirely possible to have a resource class
>>> with a single resource method that has only a path designator. Is
>>> it implied by the specification that - in practice - there will be
>>> no resource method implementation without a method designator?
>> Requests are only dispatched to methods annotated with a request
>> method designator. Methods with only an @Path are used to obtain an
>> instance of resource class to handle a sub-path, those methods
>> aren't actually dispatched to.
>>
>> Looking at the spec I see we don't currently forbid using multiple
>> request method designators on a single method so its possible to
>> write:
>>
>> @GET
>> @POST
>> Response someMethod(...)
>>
>> However, given that the semantics of the HTTP methods are distinct
>> it doesn't seem like a good idea to support this kind of thing so
>> perhaps we should disallow it and if so the method would always be
>> known implicitly.
> +1 to strictly forbid it for semanticly reasons.
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.