Implement `/id` endpoint on `rest/user.ts`

[Christopher-Hayes]

Description

The /id endpoint can be used to fetch the User of whatever token is currently being used.

It would be nice if /src/rest/user.ts implemented that API endpoint.

Ideas

• userGet(userId?: number) - Make the userId param optional on userGet(). If not supplied, the code returns the "current" user.

Motivation

@playcanvas/vscode-extension uses this endpoint because it only asks for an auth token, and with the /id endpoint it gets the current user.

Edit: I was slightly confused at first, /id returns the current user OBJECT, not just ID. But, the ID is included inside the user object.

[kpal81xd]

So these REST endpoints that I have added are not final. They are solely thin wrappers over the HTTP requests to type the request and response parameters. I intend to integrate these features in a more user friendly way for this API

[Christopher-Hayes]

So these REST endpoints that I have added are not final. They are solely thin wrappers over the HTTP requests to type the request and response parameters. I intend to integrate these features in a more user friendly way for this API

Sounds good, working with the Rest module I did notice that with types coming back unknown.

One small thing you guys could do is export the types that the Rest API is using. Something about the way Rest module is exported via the globals.ts object means all of the types on the Rest module are internal only, and I cannot import them on my typescript project.

For example for Rest functions that have specific params, this is the only way I can pull in the types into my typescript project:

type ProjectBranchesOptions = Parameters<typeof editor.rest.projects.projectBranches>[0];
type AssetGetFileOptions = Parameters<typeof editor.rest.assets.assetGetFile>[2];
type AssetUpdateData = Parameters<typeof editor.rest.assets.assetUpdate>[1];
type AssetPasteData = Parameters<typeof editor.rest.assets.assetPaste>[0];

The motivation is if I'm building a wrapper around some of these functions, I'd like to reuse the Options param on my wrapper.

[Christopher-Hayes]

Honestly, if the Rest API is meant to be stateless and the Editor-API is meant to be stateful, it might be worth thinking about splitting off the Rest API into a separate package. But, I digress.

[kpal81xd]

So these REST endpoints that I have added are not final. They are solely thin wrappers over the HTTP requests to type the request and response parameters. I intend to integrate these features in a more user friendly way for this API

Sounds good, working with the Rest module I did notice that with types coming back unknown.

One small thing you guys could do is export the types that the Rest API is using. Something about the way Rest module is exported via the globals.ts object means all of the types on the Rest module are internal only, and I cannot import them on my typescript project.

For example for Rest functions that have specific params, this is the only way I can pull in the types into my typescript project:

type ProjectBranchesOptions = Parameters<typeof editor.rest.projects.projectBranches>[0]; type AssetGetFileOptions = Parameters<typeof editor.rest.assets.assetGetFile>[2]; type AssetUpdateData = Parameters<typeof editor.rest.assets.assetUpdate>[1]; type AssetPasteData = Parameters<typeof editor.rest.assets.assetPaste>[0]; The motivation is if I'm building a wrapper around some of these functions, I'd like to reuse the Options param on my wrapper.

Yea the bundled typings are a bit messy right now as they are re-exported before being used so I am planning on making this clearer

[kpal81xd]

Honestly, if the Rest API is meant to be stateless and the Editor-API is meant to be stateful, it might be worth thinking about splitting off the Rest API into a separate package. But, I digress.

Tbh I was thinking the exact same thing since then we can use typedoc to create better documentation for our REST API endpoints dynamically and can be used internally to aid bug fixing 🤔