Projects API change log

list-projects

GET /v1/projects

• The page token query parameter was renamed from start to token.
  • For example, calling the list-projects operation changed from GET /v1/projects?limit=5&start={page_token} to GET /v1/projects?limit=5&token={page_token}.
• The first page is returned without the token query parameter in the request URL. For example, GET /v1/projects?limit=5 OR GET /v1/projects.
  • The first page is also returned when the specified page token is invalid.
• The last and previous fields are no longer supported, nor included in the response payload.

list-configs

GET /v1/projects/{project_id}/configs

• This operation is now paginated.
• A default of 10 records is returned if the page size is not specified in the limit query parameter.
  • The maximum page size is of 100 records.
• The first page is returned without the token query parameter in the request URL. For example, GET /v1/projects/{project_id}/configs/?limit=5 OR GET /v1/projects/{project_id}/configs.
  • The first page is also returned when the specified page token is invalid.

list-environments

GET /v1/projects/{project_id}/environments

• This operation is now paginated.
• A default of 10 records are returned if the page size is not specified in the limit query parameter.
  • The maximum page size is of 100 records.
• The first page is returned without the token query parameter in the request URL. For example, GET /v1/projects/{project_id}/environments/?limit=5 OR GET /v1/projects/{project_id}/environments.
  • The first page is also returned when the specified page token is invalid.

Methods to support stacking deployable architectures

Experimental

Added experimental methods to support stacking deployable architectures.

Projects and configurations changes

create-project: POST /v1/projects

• The resource_group and location are now to be embedded in the request payload. They are no longer supported as query parameters.

delete-config: PATCH /v1/projects/{project_id}/configs/{id}

• The draft_only query parameter is deprecated.
• The API now supports delete of configuration of a specified project ID and version. See projects#delete-config-version.

Renamed configuration endpoints

The following configuration endpoints are renamed as follows:

• POST /v1/projects/{project_id}/configs/{id}/check is changed to POST /v1/projects/{project_id}/configs/{id}/validate.
• POST /v1/projects/{project_id}/configs/{id}/install is changed to POST /v1/projects/{project_id}/configs/{id}/deploy.
• POST /v1/projects/{project_id}/configs/{id}/uninstall is changed to POST /v1/projects/{project_id}/configs/{id}/undeploy.

Replaced configuration endpoints

The drafts methods were replaced by the versions operations as follows:

• GET /v1/projects/{project_id}/configs/{config_id}/drafts is changed to GET /v1/projects/{project_id}/configs/{id}/versions.
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} is changed to GET /v1/projects/{project_id}/configs/{id}/versions/{version}

Configuration states

The state model for configurations is flattened. The pipeline_state is no longer available, and the one state property is now augmented to capture all possible statuses of a configuration.

The following are the new state values:

• approved
• deleted
• deleting
• deleting_failed
• discarded
• deployed
• deploying_failed
• deploying
• superceded
• undeploying
• undeploying_failed
• validated
• validating
• validating_failed

All configuration endpoints include this state property in the response model. For an example, see projects#get-config-version-response.

Configuration new metadata

The response model of configurations operations now defines new metadata in the root. If an approve job was run on a configuration, an approved_version property is included in the response payload. Similarly, if a deploy job was run on a configuration, then deployed_version and last_deployed metadata are available in the response body. Running a validation job yields the metadata last_validated, while running an undeploy job yields the metadata last_undeployed in the response.

Projects

create-project: POST /v1/projects

• For both the request & response, the name, description, and destroy_on_delete are now wrapped inside a definition object.
• Callers of this endpoint are now expected to supply the definition properties inside this wrapper, for example:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • If destroy_on_delete is not provided, a default value of true is assigned on a project create operation.
  • See projects#create-project-request.
• Similarly, in the response body, the previously mentioned properties are now available in a definition block.
  • See projects#create-project-response.

update-project: PATCH /v1/projects/{id}

• For both the request & response, the name, description, and destroy_on_delete are now wrapped inside a definition object.
• Callers of this endpoint are now expected to supply the definition properties inside this wrapper, for example:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • See projects#update-project-request.
• Similarly, in the response body, the previously mentioned properties are now available in a definition block.
  • See projects#update-project-response.

get-projects: GET /v1/projects/{id}

• In the response of this operation, the name, description, and destroy_on_delete are now wrapped inside a definition block.
  • See projects#get-project-response.

list-project: GET /v1/projects

• Each project that is returned in the response array wraps the name, description, and destroy_on_delete properties in a definition block.
  • See projects#list-projects-response.

Configurations

create-config: POST /v1/projects/{project_id}/configs

• For both request & response, the locator_id, name, labels, authorizations, compliance_profile, input, setting, description are now wrapped inside a definition object.
• Callers of this endpoint are now expected to supply the definition properties inside this wrapper, for example:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • See projects#create-config-request.
• Similarly, in the response body, the previously mentioned properties are now available in a definition block.
  • A setting property is also included in the definition block.
  • See projects#create-config-response.

update-config: PATCH /v1/projects/{project_id}/configs/{id}

• For both request & response, the locator_id, name, labels, authorizations, compliance_profile, input, setting, description are now wrapped inside a definition object.
• Callers of this endpoint are now expected to supply the definition properties inside this wrapper, for example:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • See projects#update-config-request.
• Similarly, in the response body the previously mentioned properties are moved into a definition block.
  • See projects#update-config-response.

get-config: GET /v1/projects/{id}

• In the response of this operation, the locator_id, name, labels, authorizations, compliance_profile, input, setting, description, and setting are now wrapped inside a definition object.
  • See projects#get-config-response.

list-configs: GET /v1/projects/{project_id}/configs

• In the response of this operation, the name and description are now wrapped inside a definition object.
  • See projects#list-configs-response.