Skip to content

API documentation #174

Description

@daniel78uk

We're building backend automation around RES and there's no documented, supported, stable REST API we can safely call from our own services. RES clearly has a capable API surface (the web portal uses it), but it isn't published or covered by any compatibility guarantee, so any automation we write against it is effectively built on an internal contract that can change between releases.
Concretely, we run a desired-state control plane that needs to manage RES projects programmatically — for example, assigning a per-project budget (enable_budgets + budget.budget_name) so RES enforces VDI spend — across a large and growing number of projects. Doing this by hand in the Admin portal doesn't scale, and our only programmatic option today is the undocumented internal namespace the portal happens to use. I'm always frustrated when the only way to automate RES is to reverse-engineer an internal API and re-verify it on every upgrade.

Describe the solution you'd like

A documented and maintained REST API for RES that external backends can call to automate common administrative operations — authenticated with standard RES credentials, versioned, idempotent, and covered by a published backward-compatibility policy. At minimum it should cover project lifecycle and configuration
(create/update/read/list projects, including budget association and other project settings), with clear request/response schemas in the docs The key requirement is that it's a supported contract we can depend on, not an internal endpoint that may change without notice.

Describe alternatives you've considered

  • Admin portal (manual): doesn't scale, error-prone, no GitOps/audit trail.
  • Calling the internal API the portal uses: functionally works but is undocumented/unsupported — no compatibility guarantee, requires re-verification each RES release.
  • Writing RES's DynamoDB tables directly: rejected — bypasses RES's own validation and is even more fragile.
  • Doing everything outside RES (e.g. enforcing budgets via AWS-native controls): possible for some cases but loses RES's native behaviour and doesn't cover general project automation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions