목록 프로젝트

GET /v1/projects

• 페이지 토큰 조회 매개변수의 이름이 start 에서 token(으) 로 바뀌었습니다.
  • 예를 들어, list-projects 오퍼레이션을 호출하면 GET /v1/projects?limit=5&start={page_token} 에서 GET /v1/projects?limit=5&token={page_token} 로 변경됩니다.
• 첫 번째 페이지는 요청 URL에서 토큰 조회 매개변수 없이 리턴됩니다. 예를 들어, GET /v1/projects?limit=5 또는 GET /v1/projects입니다.
  • 지정된 페이지 토큰이 올바르지 않은 경우에도 첫 번째 페이지가 리턴됩니다.
• last 및 previous 필드는 더 이상 지원되지 않으며 응답 페이로드에 포함되지 않습니다.

목록-구성

GET /v1/projects/{project_id}/configs

• 이 조작은 이제 페이지 번호가 매겨집니다.
• limit 조회 매개변수에 페이지 크기가 지정되지 않은 경우 기본값인 10개의 레코드가 리턴됩니다.
  • 최대 페이지 크기는 100개의 레코드입니다.
• 첫 번째 페이지는 요청 URL에서 토큰 조회 매개변수 없이 리턴됩니다. 예를 들어, GET /v1/projects/{project_id}/configs/?limit=5 또는 GET /v1/projects/{project_id}/configs입니다.
  • 지정된 페이지 토큰이 올바르지 않은 경우에도 첫 번째 페이지가 리턴됩니다.

목록 환경

GET /v1/projects/{project_id}/environments

• 이 조작은 이제 페이지 번호가 매겨집니다.
• limit 조회 매개변수에 페이지 크기가 지정되지 않은 경우 기본값인 10개의 레코드가 리턴됩니다.
  • 최대 페이지 크기는 100개의 레코드입니다.
• 첫 번째 페이지는 요청 URL에서 token 조회 매개변수 없이 리턴됩니다. 예를 들어, GET /v1/projects/{project_id}/environments/?limit=5 또는 GET /v1/projects/{project_id}/environments입니다.
  • 지정된 페이지 토큰이 올바르지 않은 경우에도 첫 번째 페이지가 리턴됩니다.

배치 가능한 아키텍처 스택을 지원하는 메소드

시범

배치 가능한 아키텍처 스태킹 을 지원하는 실험적 방법이 추가되었습니다.

프로젝트 및 구성 변경사항

create-project: POST /v1/projects

• resource_group 및 location 는 이제 request 페이로드에 임베드됩니다. 더 이상 조회 매개변수로 지원되지 않습니다.

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

• draft_only 조회 매개변수는 더 이상 사용되지 않습니다.
• API는 이제 지정된 프로젝트 ID및 version 의 configuration 삭제를 지원합니다. 프로젝트#delete-config - version 을 참조하십시오.

이름이 바뀐 구성 엔드포인트

다음 구성 엔드포인트의 이름은 다음과 같이 변경됩니다.

• POST /v1/projects/{project_id}/configs/{id}/check 가 POST /v1/projects/{project_id}/configs/{id}/validate 로 변경됩니다.
• POST /v1/projects/{project_id}/configs/{id}/install 가 POST /v1/projects/{project_id}/configs/{id}/deploy 로 변경됩니다.
• POST /v1/projects/{project_id}/configs/{id}/uninstall 가 POST /v1/projects/{project_id}/configs/{id}/undeploy 로 변경됩니다.

대체된 구성 엔드포인트

drafts 메소드는 다음과 같이 versions 조작으로 대체되었습니다.

• GET /v1/projects/{project_id}/configs/{config_id}/drafts 가 GET /v1/projects/{project_id}/configs/{id}/versions 로 변경됩니다.
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} 은 GET /v1/projects/{project_id}/configs/{id}/versions/{version} 로 변경됩니다.

구성 상태

configurations 의 상태 모델이 평탄화되었습니다. pipeline_state 는 더 이상 사용할 수 없으며 하나의 state 특성이 이제 configuration 의 모든 가능한 상태를 캡처하도록 기능 보강됩니다.

다음은 새 state 값입니다.

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

모든 configuration 엔드포인트는 response 모델에 이 state 특성을 포함합니다. 예를 들어, projects#get-config-version-response 를 참조하십시오.

새 메타데이터 구성

configurations 조작의 response 모델은 이제 루트에서 새 메타데이터를 정의합니다. approve 작업이 configuration 에서 실행된 경우 approved_version 특성이 response 페이로드에 포함됩니다. 마찬가지로 deploy 작업이 configuration 에서 실행된 경우 deployed_version 및 last_deployed 메타데이터를 response 본문에서 사용할 수 있습니다. validation 작업을 실행하면 last_validated 메타데이터가 생성되는 반면, undeploy 작업을 실행하면 response 에서 last_undeployed 메타데이터가 생성됩니다.

프로젝트

create-project: POST /v1/projects

• request & response 의 경우 name, description 및 destroy_on_delete 가 이제 definition 오브젝트 내에 랩핑됩니다.
• 이 엔드포인트의 호출자는 이제 이 랩퍼 내에서 정의 특성을 제공할 것으로 예상됩니다. 예를 들어, 다음과 같습니다.
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • destroy_on_delete 가 제공되지 않으면 프로젝트 작성 조작에서 기본값 true 가 지정됩니다.
  • projects#create-project - request 를 참조하십시오.
• 마찬가지로 response 본문에서 이전에 언급된 특성을 이제 definition 블록에서 사용할 수 있습니다.
  • 프로젝트#create-project - response 를 참조하십시오.

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

• request & response 의 경우 name, description 및 destroy_on_delete 가 이제 definition 오브젝트 내에 랩핑됩니다.
• 이 엔드포인트의 호출자는 이제 이 랩퍼 내에서 정의 특성을 제공할 것으로 예상됩니다. 예를 들어, 다음과 같습니다.
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • projects#update-project - request 를 참조하십시오.
• 마찬가지로 response 본문에서 이전에 언급된 특성을 이제 definition 블록에서 사용할 수 있습니다.
  • 프로젝트#update-project - response 를 참조하십시오.

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

• 이 조작의 response 에서 name, description 및 destroy_on_delete 는 이제 definition 블록 내에 랩핑됩니다.
  • 프로젝트#get-project - response 를 참조하십시오.

list-project: GET /v1/projects

• response 배열에서 리턴되는 각 프로젝트는 definition 블록에서 name, description 및 destroy_on_delete 특성을 랩핑합니다.
  • 프로젝트#list-projects - response 를 참조하십시오.

구성

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

• request & response 의 경우, locator_id, name, labels, authorizations, compliance_profile, input, setting, description 가 이제 definition 오브젝트 내에 랩핑됩니다.
• 이 엔드포인트의 호출자는 이제 이 랩퍼 내에서 정의 특성을 제공할 것으로 예상됩니다. 예를 들어, 다음과 같습니다.
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 프로젝트#create-config - request 를 참조하십시오.
• 마찬가지로 response 본문에서 이전에 언급된 특성을 이제 definition 블록에서 사용할 수 있습니다.
  • setting 특성도 definition 블록에 포함되어 있습니다.
  • 프로젝트#create-config - response 를 참조하십시오.

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

• request & response 의 경우, locator_id, name, labels, authorizations, compliance_profile, input, setting, description 가 이제 definition 오브젝트 내에 랩핑됩니다.
• 이 엔드포인트의 호출자는 이제 이 랩퍼 내에서 정의 특성을 제공할 것으로 예상됩니다. 예를 들어, 다음과 같습니다.
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 프로젝트#update-config - request 를 참조하십시오.
• 마찬가지로 response 본문에서 이전에 언급된 특성은 definition 블록으로 이동됩니다.
  • 프로젝트#update-config - response 를 참조하십시오.

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

• 이 조작의 response 에서 locator_id, name, labels, authorizations, compliance_profile, input, setting, description 및 setting 는 이제 definition 오브젝트 내에 랩핑됩니다.
  • 프로젝트#get-config - response 를 참조하십시오.

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

• 이 조작의 response 에서 name 및 description 는 이제 definition 오브젝트 내에 랩핑됩니다.
  • 프로젝트#list-configs - response 를 참조하십시오.