POC: new rest-api structure + openapi/swagger

[MathieuRA]

Description

POC for REST API redesign.

What about: tsoa?

For all objects that extend AbstractCollection, /rest/v0/${type}/ and /rest/v0/${type}/:id are automatically registered. For collections that are not a XAPI collection, such as users, simply add the getObjects and getObject methods in the class.
If the endpoint point to one object. (/rest/v0/users/1234/foo), the object will be automatically resolved (using getObject) and injected in res.locals.object

/rest/v0/dashboard
/rest/v0/hosts
/rest/v0/hosts/:id
/rest/v0/users
/rest/v0/users/:id
/rest/v0/vms
/rest/v0/vms/foo
/rest/v0/vms/:id
/rest/v0/vms/:id/name_label

endpoint rules:

/rest/<version>/ressources/<ressource_id>/sub-resource
/rest/<version>/ressources/<ressource_id>/actions/<action>
to create/delete/update a ressource (e.g. VM), always do a POST/DELETE/PATCH/ requestion on the ressource.
POST/DELETE/PATCH rest/v0/vms/

Checklist

• Can all actions be performed in a group? (create multiple VMs, delete multiple VMs, start mutlitple VMs)

• [-] use TS (and update the build or maybe put the REST API in @xen-orchestra?)

  #xo-server/package.json
  ...
  "build:rest-api": "tsc --project src/_rest-api/tsconfig.json",
  "build:rm-rest-api-build": "rm -rf src/rest-api",
  "_build": "npm run build:rest-api && index-modules --index-file index.mjs src/api src/xapi/mixins src/xo-mixins src/rest-api && babel --delete-dir-on-start --keep-file-extension --source-maps --out-dir=dist/ src/ && npm run build:rm-rest-api-build",
  ...
  

• expose an action

• handle sync an async actions

• handle AbstractCollection routes with user permission

  • Filter Objects based on ACLs user

• expose openapi + swagger docs

• Commit

  • Title follows commit conventions
  • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
  • If bug fix, add Introduced by

• Changelog

  • If visible by XOA users, add changelog entry
  • Update "Packages to release" in CHANGELOG.unreleased.md

• PR

  • If UI changes, add screenshots
  • If not finished or not tested, open as Draft

Review process

This 2-passes review process aims to:

• develop skills of junior reviewers
• limit the workload for senior reviewers
• limit the number of unnecessary changes by the author

1. The author creates a PR.
2. Review process:
   1. The author assigns the junior reviewer.
   2. The junior reviewer conducts their review:
      • Resolves their comments if they are addressed.
      • Adds comments if necessary or approves the PR.
   3. The junior reviewer assigns the senior reviewer.
   4. The senior reviewer conducts their review:
      • If there are no unresolved comments on the PR → merge.
      • Otherwise, we continue with 3.
3. The author responds to comments and/or makes corrections, and we go back to 2.

Notes:

1. The author can request a review at any time, even if the PR is still a Draft.
2. In theory, there should not be more than one reviewer at a time.
3. The author should not make any changes:
   • When a reviewer is assigned.
   • Between the junior and senior reviews.