Thanks, I understand.
Imho this is still somehow poor API design.
The ToS require to always check whether a user’s auth token is still valid (to prevent a user from appearing logged-in after he has revoked his token).
Also, an application probably wants to check if the user’s information is still up-to-date.
Using this endpoint, it’s possible to combine these two things.
However, the API does respond either with 400 Bad Request (= you did something wrong syntactically) or with the user (corresponding to the auth token) depending on whether the authorization is valid or not, only because there are “multiple ways” to talk to the endpoint (misusing an authorization token as one of the input parameters).
Imho, a better solution to this would be to use two different resources: One for fetching arbitrary users (no authorization required) and one for fetching the auth token’s user (authorization required).
That would make the design of an API client a lot easier.
Just a quick thought, I might be wrong with this.
Also, when using PUT on the same resource (user editing), but without the Client-ID and the Authorization request header, the 401 Unauthorized response does also not contain a WWW-Authenticate response header. (Wrong or outdated documentation?)
Furthermore, when a user revokes his token by disconnecting the application and then this token is used within a request, a 403 Forbidden is returned with this message in the body: Missing user:edit scope
That makes absolutely no sense to me (neither the response status, nor the message).
Also, the 401 Unauthorized is only returned if both the Client-ID and the Authorization request header are missing. If one of them is present, 403 Forbidden is returned.
Keeping in mind that sending Client-ID is considered mandatory, how can a request without it be authorized, but doing something forbidden due to missing permissions?
Oh and btw, I couldn’t test if a valid token actually alters the description, because 500 Internal Server Error.