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