> GET /user/:user/exists
Wat. Use HEAD. Seriously.
Also, what is ":user" - how do you define the way an account is found in the tree?
How do you handle complex trees with potentially conflicting values for the attribute you use as 'username' ?
Why are their dedicated endpoints for password, expiry, enable/disable/unlock. These are all just attributes on the user object.
That checks sAMAccountName, which is unique. Searches that can return multiple results will do so.
> Why are their dedicated endpoints for password, expiry, enable/disable/unlock. These are all just attributes on the user object.
It wouldn't be very user friendly to require a PATCH so a user can change a password. All of these operations are quite granular. You aren't going to enable an account and change a password at the same time very often.
The overriding drive in building this was ease of use, because that bugs me with AD. I'm definitely open to suggestions, though :)
> That checks sAMAccountName, which is unique
Only in Microsoft's schema. If you want to work with just AD, thats fine, but you shouldn't claim to be LDAP compatible if you only work with a single vendor's schema.
> It wouldn't be very user friendly to require a PATCH so a user can change a password
Why? It's a REST API, you're talking to it from code, you aren't asking users to write curl requests.
> You aren't going to enable an account and change a password at the same time very often.
I see you've never worked in a support environment before. If the account becomes locked, its usually because the user tried the wrong password too many times. So, they contact support who can unlock it, and invariably will need to reset the password at the same time.
> I'm definitely open to suggestions
Well I think you need to decide if its targeting AD specifically or any LDAP directory server. If it's the latter, it needs to be a lot more configurable .
