Resource Identifiers

API view, update, and delete operations typically target a single resource per request. Resources can be identified either

  1. By ID, or

  2. By name + parent identifier(s)

Parent identifiers are needed when the name alone is not enough to uniquely determine a resource. IDs are v4 UUIDs and therefore globally unique. Names, however, are only unique within a parent container (e.g., instance names within a project, subnet names within a VPC).

Example: Project

Projects are a top-level resource, so a name is sufficient to uniquely determine a project. Either of these will work to fetch a project:

  • /v1/projects/<project ID>

  • /v1/projects/<project name>

Example: Disk in Project

Every disk is contained in a parent project. Any of the following will work to specify the disk:

  • (disk ID)

  • (disk name, project ID)

  • (disk name, project name)

The resource’s own name or ID is included in the path, while parent identifiers go in query params. The corresponding URIs for a GET request for that disk would be:

  • /v1/disks/<disk ID>

  • /v1/disks/<disk name>?project=<project ID>

  • /v1/disks/<disk name>?project=<project name>

Example: Subnet in VPC in Project

The above logic extends to resources that are nested further. VPC subnets have a parent VPC, and VPCs have a parent project. Any of the following will work to specify a subnet:

  • (subnet ID)

  • (subnet name, VPC ID)

  • (subnet name, VPC name, project ID)

  • (subnet name, VPC name, project name)

The corresponding URIs for a GET request for that subnet would be:

  • /v1/vpc-subnets/<subnet ID>

  • /v1/vpc-subnets/<subnet name>?vpc=<vpc ID>

  • /v1/vpc-subnets/<subnet name>?vpc=<vpc name>&project=<project ID>

  • /v1/vpc-subnets/<subnet name>?vpc=<vpc name>&project=<project name>

Last updated