[jax-rs-spec users] [jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

From: Sergey Beryozkin <>
Date: Tue, 13 Nov 2012 12:02:40 +0000

On 12/11/12 19:27, Markus KARG wrote:
>> Well, if we talk about an HTTP client making the decisions on how to
>> talk to the server application, the fact that the server may've been
>> implemented with Java EE is an implementation detail of the server.
>> You are proposing for the spec to support for the client be written
>> with the specific knowledge that the server is running on top of EE.
>> How will this client application if someone rewrites the server with
>> PHP ? Will that break the client expectations ?
> No I do not proposing the spec to support anything special in the client for
> anything special in the server, please carefully check what I actually
> proposed. The client is dependent of pure http. The server is producing pure
> http. The only relation to Java EE is on the server side.
> As the interface is defined by pure http means, certainly such a client will
> run rather perfectly with PHP server. I do not bind the client to anything
> server specific. Nothing broken.

OK, lets talk practical.

here is my resource:

public class Resource {
   public Response getA() {}

   public Response postA() {}

   public Response postB() {}

The (UI) client logs in, and it's allocated 'AdminA' role. The UI can
access '/a' and '/b'.

Here are my questions:

At what point do you expect to ping the runtime with OPTIONS ?

Why it will be cheaper (and also less expensive for the server) than
attempting to access '/b' and disable the button allowing the user to
access "/b" upon the authorization failure ?

Do you expect POST be listed in Allowed ? How will you know that "/b"
can not be accessed ?