Listenprojekte

GET /v1/projects

• Der Abfrageparameter für Seitentoken wurde von start in token umbenannt.
  • Beispiel: Der Aufruf der Operation list-projects wurde von GET /v1/projects?limit=5&start={page_token} in GET /v1/projects?limit=5&token={page_token} geändert.
• Die erste Seite wird ohne den Tokenabfrageparameter in der Anforderungs-URL zurückgegeben. Beispiel: GET /v1/projects?limit=5 oder GET /v1/projects.
  • Die erste Seite wird ebenfalls zurückgegeben, wenn das angegebene Seitentoken ungültig ist.
• Die Felder last und previous werden nicht mehr unterstützt und nicht mehr in die Antwortnutzdaten eingeschlossen.

list-configs

GET /v1/projects/{project_id}/configs

• Diese Operation ist jetzt paginiert.
• Ein Standardwert von 10 Datensätzen wird zurückgegeben, wenn die Seitengröße nicht im Abfrageparameter limit angegeben ist.
  • Die maximale Seitengröße beträgt 100 Datensätze.
• Die erste Seite wird ohne den Tokenabfrageparameter in der Anforderungs-URL zurückgegeben. Beispiel: GET /v1/projects/{project_id}/configs/?limit=5 oder GET /v1/projects/{project_id}/configs.
  • Die erste Seite wird ebenfalls zurückgegeben, wenn das angegebene Seitentoken ungültig ist.

Listenumgebungen

GET /v1/projects/{project_id}/environments

• Diese Operation ist jetzt paginiert.
• Es werden standardmäßig 10 Datensätze zurückgegeben, wenn die Seitengröße nicht im Abfrageparameter limit angegeben ist.
  • Die maximale Seitengröße beträgt 100 Datensätze.
• Die erste Seite wird ohne den Abfrageparameter token in der Anforderungs-URL zurückgegeben. Beispiel: GET /v1/projects/{project_id}/environments/?limit=5 oder GET /v1/projects/{project_id}/environments.
  • Die erste Seite wird ebenfalls zurückgegeben, wenn das angegebene Seitentoken ungültig ist.

Methoden zur Unterstützung des Stapelns implementierbarer Architekturen

Experimentell

Es wurden experimentelle Methoden zur Unterstützung von stapelbaren implementierbaren Architekturen hinzugefügt.

Änderungen an Projekten und Konfigurationen

create-project: POST /v1/projects

• resource_group und location müssen jetzt in die request-Nutzdaten eingebettet werden. Sie werden nicht mehr als Abfrageparameter unterstützt.

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

• Der Abfrageparameter draft_only ist veraltet.
• Die API unterstützt jetzt das Löschen von configuration einer angegebenen Projekt-ID und version. Siehe projects#delete-config-version.

Umbenannte Konfigurationsendpunkte

Die folgenden Konfigurationsendpunkte werden wie folgt umbenannt:

• POST /v1/projects/{project_id}/configs/{id}/check wird in POST /v1/projects/{project_id}/configs/{id}/validate geändert.
• POST /v1/projects/{project_id}/configs/{id}/install wird in POST /v1/projects/{project_id}/configs/{id}/deploy geändert.
• POST /v1/projects/{project_id}/configs/{id}/uninstall wird in POST /v1/projects/{project_id}/configs/{id}/undeploy geändert.

Ersetzte Konfigurationsendpunkte

Die drafts-Methoden wurden wie folgt durch die versions-Operationen ersetzt:

• GET /v1/projects/{project_id}/configs/{config_id}/drafts wird in GET /v1/projects/{project_id}/configs/{id}/versions geändert.
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} wird geändert in GET /v1/projects/{project_id}/configs/{id}/versions/{version}

Konfigurationsstatus

Das Statusmodell für configurations ist abgeflacht. pipeline_state ist nicht mehr verfügbar und die Eigenschaft state wird jetzt erweitert, um alle möglichen Status eines configuration s zu erfassen.

Im Folgenden sind die neuen state-Werte aufgeführt:

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

Alle configuration-Endpunkte enthalten diese Eigenschaft state im response-Modell. Ein Beispiel finden Sie unter projects#get-config-version-response.

Neue Metadaten für Konfiguration

Das response-Modell der configurations-Operationen definiert jetzt neue Metadaten im Stammverzeichnis. Wenn ein approve-Job auf einem configuration ausgeführt wurde, ist die Eigenschaft approved_version in den response-Nutzdaten enthalten. Wenn ein deploy-Job auf einem configuration ausgeführt wurde, sind die Metadaten deployed_version und last_deployed im Hauptteil von response verfügbar. Die Ausführung eines validation-Jobs liefert die Metadaten last_validated, während die Ausführung eines undeploy-Jobs die Metadaten last_undeployed in der response liefert.

Projekte

create-project: POST /v1/projects

• Für request & response werden name, description und destroy_on_delete jetzt in ein definition-Objekt eingeschlossen.
• Von den Aufrufenden dieses Endpunkts wird jetzt erwartet, dass sie die Definitionseigenschaften innerhalb dieses Wrappers bereitstellen. Beispiel:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • Wenn destroy_on_delete nicht angegeben ist, wird bei einer Projekterstellungsoperation der Standardwert true zugewiesen.
  • Siehe Projekte#create-project-request.
• In ähnlicher Weise sind die zuvor genannten Eigenschaften im response-Hauptteil jetzt in einem definition-Block verfügbar.
  • Siehe Projekte#create-project-response.

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

• Für request & response werden name, description und destroy_on_delete jetzt in ein definition-Objekt eingeschlossen.
• Von den Aufrufenden dieses Endpunkts wird jetzt erwartet, dass sie die Definitionseigenschaften innerhalb dieses Wrappers bereitstellen. Beispiel:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • Siehe Projekte#update-project-request.
• In ähnlicher Weise sind die zuvor genannten Eigenschaften im response-Hauptteil jetzt in einem definition-Block verfügbar.
  • Siehe Projekte#update-project-response.

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

• In der response dieser Operation sind die name, description und destroy_on_delete jetzt in einem definition-Block eingeschlossen.
  • Siehe Projekte#get-project-response.

list-project: GET /v1/projects

• Jedes Projekt, das im Array response zurückgegeben wird, schließt die Eigenschaften name, description und destroy_on_delete in einen definition-Block ein.
  • Siehe Projekte#list-projects-response.

Konfigurationen

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

• Für request & response werden locator_id, name, labels, authorizations, compliance_profile, input, setting, description jetzt in ein definition-Objekt eingeschlossen.
• Von den Aufrufenden dieses Endpunkts wird jetzt erwartet, dass sie die Definitionseigenschaften innerhalb dieses Wrappers bereitstellen. Beispiel:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Siehe Projekte#create-config-request.
• In ähnlicher Weise sind die zuvor genannten Eigenschaften im response-Hauptteil jetzt in einem definition-Block verfügbar.
  • Eine Eigenschaft setting ist auch im Block definition enthalten.
  • Siehe Projekte#create-config-response.

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

• Für request & response werden locator_id, name, labels, authorizations, compliance_profile, input, setting, description jetzt in ein definition-Objekt eingeschlossen.
• Von den Aufrufenden dieses Endpunkts wird jetzt erwartet, dass sie die Definitionseigenschaften innerhalb dieses Wrappers bereitstellen. Beispiel:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Siehe Projekte#update-config-request.
• Ebenso werden im response-Hauptteil die zuvor genannten Eigenschaften in einen definition-Block verschoben.
  • Siehe Projekte#update-config-response.

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

• In der response dieser Operation werden die locator_id, name, labels, authorizations, compliance_profile, input, setting, description und setting jetzt in ein definition-Objekt eingeschlossen.
  • Siehe Projekte#get-config-response.

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

• In der response dieser Operation sind name und description jetzt in ein definition-Objekt eingeschlossen.
  • Siehe Projekte#list-configs-response.