Skip to content

Generic REST API Layer

The generic REST API layer provides a unified interface for interacting with Dell Automation Platform (DAP) resources across different components, such as the portal and the orchestrator. This layer abstracts the underlying HTTP communication, manages a static registry of available resource types and their endpoints, and implements kubectl-style verbs to allow users to perform operations like get, create, delete, and describe on any registered resource.

The RestClient class in src/dap/rest/client.py serves as the core HTTP client, targeting a specific component server (either the portal or a selected orchestrator outcome) 1. It handles authentication by attaching the bearer token as a raw Authorization header, noting that DAP does not use the Bearer scheme on these endpoints. The client supports several request-preview flags: --curl prints the equivalent curl command for any verb instead of executing it, --dry-run=client validates a mutation locally without calling the API, and --dry-run=api prints a mutation’s request without executing it. Read verbs ignore --dry-run settings, matching the reference CLI behavior, while --curl applies to reads as well.

The client also handles cursor pagination for list operations via the list_all method, which follows next links in the response until all items are retrieved or a page limit is reached 2. It uses httpx for making requests and raises DapError for HTTP errors, including specific handling for 401 unauthorized responses.

diagram

The resource registry, defined in src/dap/rest/registry.py, maintains an immutable index of resource types for one or more components 3. Since DAP ships no resource-discovery endpoint, the catalog of resource types, their endpoint paths, and their verb sets are carried in the codebase. Some endpoints are irregular; for example, clusters is served at /rest/v1/endpoints?type=CLUSTER rather than /rest/v1/clusters.

The Resource dataclass defines a resource type with attributes such as name, kind, component, verbs, get_path, shortnames, list_key, and default_query. The Registry class indexes these resources by component and token (name, kind, or shortname) for efficient lookup. The load_registry function builds the registry by combining resources from per-component catalog modules, portal and orchestrator. These catalogs are generated by scripts/gen_catalog.py from the API registry (docs/api-registry/registry.json) and should not be edited by hand 4 5.

The registry defines the set of verbs available for each resource type, such as get, describe, create, apply, delete, patch, action, wait, logs, events, diff, and explain 4 5. These verbs are implemented as kubectl-style commands, allowing users to interact with resources in a consistent manner. For example, the blueprints resource in the orchestrator supports get, describe, create, apply, delete, patch, action, diff, and explain verbs 4. Similarly, the deployments resource supports get, describe, create, apply, delete, patch, action, wait, logs, events, diff, and explain verbs.

The explain verb is available for all resources, providing information about the resource type 5. Some resources, like alerts and audit-logs in the orchestrator, only support the explain verb, indicating they are explain/describe-only with no list call 3 4. The get_path attribute specifies the endpoint relative to the component server, and list_key indicates the envelope key holding the list in the response 3. For resources with irregular endpoints, default_query provides additional query parameters, such as type=CLUSTER for clusters.