You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious about anyone's opinion on how (or if) I should implement the "ID" in the API path.
Normally in a REST api, you'd have endpoints that accept an ID to act on a particular entity. E.g. - /customers/{id}
At first, I wanted to do this here for AD as well, but each attribute candidate that I think of, I have reservations about.
distinguishedName
The obvious choice as the LDAP libraries need this to do most operations against a single object. But this is lengthy and it's possible that certain DNs would require URL encoding.
the rest of the attribute options below all have the downside that an AD search query must be performed prior to acting on the object.
objectGUID
Pro is that is guaranteed to be unique and its format is standard.
objectSID
Most will be longer than objectGUID but still fairly standard. Can code things into the API that restricts actions to the built-in SIDs. Because SIDs have a domain component to them, it would negate the need for specifying domains when the API has multiple registered.
Are there any other attribute candidates that anyone can think of?
Do you think this API should have an identity attribute declared for its endpoints? And if so, which one?
Distinguished Name
0%
Object GUID
0%
Object SID
0%
No need for identity-based endpoints - Query parameters are fine.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm curious about anyone's opinion on how (or if) I should implement the "ID" in the API path.
Normally in a REST api, you'd have endpoints that accept an ID to act on a particular entity. E.g. -
/customers/{id}At first, I wanted to do this here for AD as well, but each attribute candidate that I think of, I have reservations about.
distinguishedName
the rest of the attribute options below all have the downside that an AD search query must be performed prior to acting on the object.
objectGUID
objectSID
Are there any other attribute candidates that anyone can think of?
0 votes ·
Beta Was this translation helpful? Give feedback.
All reactions