リスト・プロジェクト

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 の削除をサポートするようになりました。 projects#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 は使用できなくなり、1 つの state プロパティーが拡張されて、 configuration の考えられるすべての状況が取り込まれるようになりました。

以下に、新しい state 値を示します。

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

すべての configuration エンドポイントは、この state プロパティーを response モデルに組み込みます。 例については、 projects#get-config-version-response を参照してください。

新規メタデータの構成

configurations 操作の response モデルで、新規メタデータがルートに定義されるようになりました。 approve ジョブが configuration で実行された場合、 approved_version プロパティーが response ペイロードに含まれます。 同様に、 deploy ジョブが configuration で実行された場合、 response 本体で deployed_version および last_deployed メタデータが使用可能です。 validation ジョブを実行するとメタデータ last_validated が生成され、 undeploy ジョブを実行するとメタデータ last_undeployed が response に生成されます。

プロジェクト

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 ブロックで使用可能になりました。
  • projects#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 ブロックで使用可能になりました。
  • projects#update-project-response を参照してください。

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

• この操作の response では、 name、 description、および destroy_on_delete が definition ブロック内でラップされるようになりました。
  • projects#get-project-response を参照してください。

list-project: GET /v1/projects

• response 配列で返される各プロジェクトは、 definition ブロック内の name、 description、および destroy_on_delete プロパティーをラップします。
  • projects#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”}.
  • projects#create-config-request を参照してください。
• 同様に、 response 本体では、前述のプロパティーが definition ブロックで使用可能になりました。
  • setting プロパティーも definition ブロックに含まれています。
  • projects#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”}.
  • projects#update-config-request を参照してください。
• 同様に、 response 本体では、前述のプロパティーが definition ブロックに移動されます。
  • projects#update-config-response を参照してください。

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

• この操作の response では、 locator_id、 name、 labels、 authorizations、 compliance_profile、 input、 setting、 description、および setting が definition オブジェクト内でラップされるようになりました。
  • projects#get-config-response を参照してください。

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

• この操作の response では、 name と description が definition オブジェクト内でラップされるようになりました。
  • projects#list-configs-response を参照してください。