Description of the Change

Expose api/username/available endpoint.

The Users().IsUsernameAvailable() returns true if available, false if not, and error if the username does not meet the validation requirements (1-20 \w characters, equivalent to [a-zA-Z0-9_]).

Issue or RFC

17 username/available

https://misskey.io/api-doc#tag/users/operation/username/available

Alternate Designs

My first commit was to create a new Username() service. However, after reading the issue notes, it was suggested that username/available should be renamed such that it could fit into the Users() service.

Possible Drawbacks

I followed some examples within the code, performing validation of the input. For username, the length must be 1-20 characters. With this commit, this validation is being performed on the client (in go-misskey). The same error would be returned by the server, so this avoids an extra API call when the validation fails. However, if the API is updated in future, for example to allow usernames of longer length, this means that the go-misskey code would need to change to also allow usernames of longer length. It's just a debate between performing validation on the client side or the server side.

Verification Process

There is an example endpoint. I have run this against slippy.xyz and it works successfully to identify which usernames are available.

Release Notes

All endpoints are available for username.

yitsushi / go-misskey

Username/available #106