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:
@Path("/")
public class Resource {
@GET
@Path("/a")
@RolesAllowed("AdminA")
public Response getA() {}
@POST
@Path("/a")
@RolesAllowed("AdminA")
public Response postA() {}
@POST
@Path("/b")
@RolesAllowed("AdminB")
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 ?
Sergey