On 23 November 2015 at 15:06, Bill Burke <bburke(a)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