proyectos de lista

GET /v1/projects

• El parámetro de consulta de señal de página se ha renombrado de start a token.
  • Por ejemplo, la llamada a la operación list-projects ha cambiado de GET /v1/projects?limit=5&start={page_token} a GET /v1/projects?limit=5&token={page_token}.
• La primera página se devuelve sin el parámetro de consulta de señal en el URL de solicitud. Por ejemplo, GET /v1/projects?limit=5 o GET /v1/projects.
  • La primera página también se devuelve cuando la señal de página especificada no es válida.
• Los campos last y previous ya no están soportados, ni incluidos en la carga útil de respuesta.

configuración de lista

GET /v1/projects/{project_id}/configs

• Esta operación ahora está paginada.
• Se devuelve un valor predeterminado de 10 registros si no se especifica el tamaño de página en el parámetro de consulta limit.
  • El tamaño máximo de página es de 100 registros.
• La primera página se devuelve sin el parámetro de consulta de señal en el URL de solicitud. Por ejemplo, GET /v1/projects/{project_id}/configs/?limit=5 o GET /v1/projects/{project_id}/configs.
  • La primera página también se devuelve cuando la señal de página especificada no es válida.

lista-entornos

GET /v1/projects/{project_id}/environments

• Esta operación ahora está paginada.
• Se devuelve un valor predeterminado de 10 registros si no se especifica el tamaño de página en el parámetro de consulta limit.
  • El tamaño máximo de página es de 100 registros.
• La primera página se devuelve sin el parámetro de consulta token en el URL de solicitud. Por ejemplo, GET /v1/projects/{project_id}/environments/?limit=5 o GET /v1/projects/{project_id}/environments.
  • La primera página también se devuelve cuando la señal de página especificada no es válida.

Métodos para dar soporte al apilamiento de arquitecturas desplegables

Experimental

Se han añadido métodos experimentales para dar soporte a apilamiento de arquitecturas desplegables.

Cambios en proyectos y configuraciones

create-project: POST /v1/projects

• Ahora resource_group y location se van a incluir en la carga útil de request. Ya no están soportados como parámetros de consulta.

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

• El parámetro de consulta draft_only está en desuso.
• La API ahora da soporte a la supresión de configuration de un ID de proyecto especificado y version. Consulte proyectos#delete-config-version.

Puntos finales de configuración renombrados

Los siguientes puntos finales de configuración se renombran como se indica a continuación:

• POST /v1/projects/{project_id}/configs/{id}/check se ha cambiado a POST /v1/projects/{project_id}/configs/{id}/validate.
• POST /v1/projects/{project_id}/configs/{id}/install se ha cambiado a POST /v1/projects/{project_id}/configs/{id}/deploy.
• POST /v1/projects/{project_id}/configs/{id}/uninstall se ha cambiado a POST /v1/projects/{project_id}/configs/{id}/undeploy.

Puntos finales de configuración sustituidos

Los métodos drafts se han sustituido por las operaciones versions de la forma siguiente:

• GET /v1/projects/{project_id}/configs/{config_id}/drafts se ha cambiado a GET /v1/projects/{project_id}/configs/{id}/versions.
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} se ha cambiado a GET /v1/projects/{project_id}/configs/{id}/versions/{version}

Estados de configuración

El modelo de estado para configurations se ha aplanado. pipeline_state ya no está disponible y la propiedad state se ha aumentado para capturar todos los estados posibles de un configuration.

Los siguientes son los nuevos valores de state:

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

Todos los puntos finales de configuration incluyen esta propiedad state en el modelo response. Para ver un ejemplo, consulte proyectos#get-config-version-response.

Configuración de nuevos metadatos

El modelo response de operaciones configurations ahora define nuevos metadatos en la raíz. Si un trabajo approve se ha ejecutado en un configuration, se incluye una propiedad approved_version en la carga útil de response. De forma similar, si se ha ejecutado un trabajo deploy en un configuration, los metadatos deployed_version y last_deployed están disponibles en el cuerpo response. La ejecución de un trabajo validation genera los metadatos last_validated, mientras que la ejecución de un trabajo undeploy genera los metadatos last_undeployed en response.

Proyectos

create-project: POST /v1/projects

• Para request & response, name, description y destroy_on_delete ahora están envueltos dentro de un objeto definition.
• Ahora se espera que los llamadores de este punto final suministren las propiedades de definición dentro de este derivador, por ejemplo:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • Si no se proporciona destroy_on_delete, se asigna un valor predeterminado de true en una operación de creación de proyecto.
  • Consulte proyectos#create-project-request.
• De forma similar, en el cuerpo de response, las propiedades mencionadas anteriormente ahora están disponibles en un bloque definition.
  • Consulte proyectos#create-project-response.

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

• Para request & response, name, description y destroy_on_delete ahora están envueltos dentro de un objeto definition.
• Ahora se espera que los llamadores de este punto final suministren las propiedades de definición dentro de este derivador, por ejemplo:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • Consulte proyectos#update-project-request.
• De forma similar, en el cuerpo de response, las propiedades mencionadas anteriormente ahora están disponibles en un bloque definition.
  • Consulte proyectos#update-project-response.

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

• En el response de esta operación, name, description y destroy_on_delete están ahora envueltos dentro de un bloque definition.
  • Consulte proyectos#get-project-response.

list-project: GET /v1/projects

• Cada proyecto que se devuelve en la matriz response envuelve las propiedades name, description y destroy_on_delete en un bloque definition.
  • Consulte proyectos#list-projects-response.

Configuraciones

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

• Para request & response, locator_id, name, labels, authorizations, compliance_profile, input, setting, description ahora se envuelven dentro de un objeto definition.
• Ahora se espera que los llamadores de este punto final suministren las propiedades de definición dentro de este derivador, por ejemplo:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Consulte proyectos#create-config-request.
• De forma similar, en el cuerpo de response, las propiedades mencionadas anteriormente ahora están disponibles en un bloque definition.
  • También se incluye una propiedad setting en el bloque definition.
  • Consulte proyectos#create-config-response.

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

• Para request & response, locator_id, name, labels, authorizations, compliance_profile, input, setting, description ahora se envuelven dentro de un objeto definition.
• Ahora se espera que los llamadores de este punto final suministren las propiedades de definición dentro de este derivador, por ejemplo:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Consulte proyectos#update-config-request.
• De forma similar, en el cuerpo response, las propiedades mencionadas anteriormente se mueven a un bloque definition.
  • Consulte proyectos#update-config-response.

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

• En el response de esta operación, los locator_id, name, labels, authorizations, compliance_profile, input, setting, description y setting se envuelven ahora dentro de un objeto definition.
  • Consulte proyectos#get-config-response.

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

• En el response de esta operación, name y description se envuelven ahora dentro de un objeto definition.
  • Consulte proyectos#list-configs-response.