For all the top-level entities in v2 - users, organizations, projects, workspaces` - there are two modes of identification.

There is a unique id (ie, 3590cc6d-92aa-478a-b6a8-62b1518cc599) and a friendly name that is enforced to be unique (ie, my-project).

Our API routes currently only support the friendly name.

So for the above example, in the current world - assuming we're calling as a user with perms to read the org / project:

• GET /api/v2/projects/acme-corp/my-project would succeed
• GET /api/v2/projects/acme-corp/3590cc6d-92aa-478a-b6a8-62b1518cc599 would fail

This is problematic - because in some cases, we only have the unique id to work with.

For example, in the GET workspaces API:

• GET /api/v2/workspaces/me/my-workspace

The following is returned:

{"id":"3590cc6d-92aa-478a-b6a8-62b1518cc599","created_at":"2022-02-28T18:33:24.724734181Z","updated_at":"2022-02-28T18:33:24.724734291Z","owner_id":"4aeaa38d-d119-47f8-9008-3858e145a076","project_id":"0b0fa178-ab74-41c7-81e3-583a9bc08610","name":"my-workspace"}

To make use of this data - and to read information about the project or organization of the workspace, the apis need to also support referencing by unique id.

The work required is:

• Update ExtractUserParam to support referencing by friendly-name OR unique ID
• Update ExtractProjectParam to support referencing by friendly-name OR unique ID
• Update ExtractUserParam to support referencing by friendly-name OR unique ID
• Add relevant test cases