On 23 November 2015 at 15:06, Bill Burke <bburke@redhat.com> wrote:


On 11/23/2015 3:19 AM, Stian Thorgersen wrote:
    Removing clientID doesn't work for built-in clients like account,
    broker, admin-console, etc.  These all need to be located using a
    predetermined name.  You'd have to figure out an additional
    alternative to refactor that.


Is it not actually bad that they are located using predetermined names?
If lookup is on id, you know for a fact that it's the correct client and
not just something with the same name.


Remember, the predetermined names are "account", "broker" etc.  These are non-unique names.  They have to be predetermined or at least indexed in a realm attribute by a predetermined name.

My thinking was we'd add realm attributes
 



I never liked it when we had multiple entry points to the same resource.
What about using something like:

GET ../users?username=<myusername>&single=true
GET ../users?email=<myemail>&single=true

That returns a single UserRepresentation including 'self'
(../users/<user-id>).

Same for groups:

GET ../groups?path=<url encoded path>&single=true


That works too.

It's slightly more elegant isn't it? As everything has 1 place in the endpoints, rather than multiple. With a 'search' option under 'users' we'd only have:

/users

But, with the alternative approach (users-by-username, group-by-path, etc) we end up with multiple locations:

/users
/users-by-email
/users-by-username

Which I think is harder to use + not as nice for audit/logging

 


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com