users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Another backtracking problem

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 23 Jan 2015 17:38:02 +0000

Actually spotted a text from your colleague after I sent it but I'd
still have a 'one line' neutral example to look at.

There was only one issue I recall, where a subresource was discarded
even though no matching verbs were available on the current resource,
but only if a subresource locator had an equal path.

@Path("")
public Resource {
   @Path("aa")
   @GET
   public Response get();


   @Path("aa")
   public ResourceSub sub();
}


public ResourceSub {
   @PUT
   public Response put();
}


PUT /aa

does not match ResourceSub.sub().


but in

@Path("")
public Resource {
   @Path("a{id}")
   @GET
   public Response get();


   @Path("a1")
   public ResourceSub sub();
}


public ResourceSub {
   @PUT
   public Response put();
}


PUT /a1

does match ResourceSub.sub().

It is not consistent. But we did spend a lot of time talking about it
and I guess it is a minor issue after all, not a major
constraint...There are some possible issues on the negative path for
HEAD/etc so let it be the way it is now...

Sergey





On 23/01/15 16:00, Sergey Beryozkin wrote:
> Can you clarify please ?
>
> Sergey
>
> On 23/01/15 14:40, Bill Burke wrote:
>> Coincidently, today, my co-lead on a security project asked me if we
>> could shorted the URLs of our REST service endpoints...Unfortunately I
>> can't because of the JAX-RS matching algorithm...
>>
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: Re: [keycloak-dev] Shortening URLs
>> Date: Fri, 23 Jan 2015 09:36:09 -0500
>> From: Bill Burke <bburke_at_redhat.com>
>> To: keycloak-dev_at_lists.jboss.org
>>
>>
>>
>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>> Our URLs are quite long, examples:
>>>
>>> *
>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>> * http://localhost:8080/auth/realms/master/account
>>>
>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>
>>> * http://localhost:8080/auth/master/oidc/login
>>> * http://localhost:8080/auth/master/account
>>>
>>> That would require moving everything under a realm and I guess we'd
>>> need to hard-wire the protocols, but I think that should be fine.
>>>
>>
>> Wouldn't work for multiple reasons.
>>
>> * protocols/* exists to be able to plugin different protocols (oidc,
>> saml, etc.)
>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
>> for both resource classes and resource locators we need both a "realms"
>> and "protocols" qualifier.
>>
>> Its really funny you bring this up now because I've renewed my argument
>> with JAX-RS JSR just 2 minutes ago! Synchronicity!
>>
>>
>>> We also need to make sure we can just the root context:
>>>
>>> * http://localhost:8080/master/oidc/login
>>> * http://localhost:8080/master/account
>>>
>>> We can also introduce other mechanisms to select the realm. For
>>> example a server with single realm can just omit it altogether:
>>>
>>> * http://localhost:8080/oidc/login
>>> * http://localhost:8080/account
>>>
>>> And we could allow setting what domains uses what realms:
>>>
>>> * http://keycloak-master/oidc/login
>>> * http://keycloak-other/oidc/login
>>>
>>
>> You don't think its better to have URLS be consistent?
>>
>>
>