カタログオブジェクトの更新
PATCH リクエストのパスにIDを含めることで、Catalog オブジェクトの一部を更新できます。 このドキュメントでは、カタログオブジェクトに対して PATCH 操作を実行する次の 2 つの方法について説明します。
- フィールドを使用する
- JSON パッチ表記を使用する
フィールドを使用した更新
次の呼び出し例は、フィールドと値を使用してオブジェクトを更新する方法を示しています。
API 形式
PATCH /{OBJECT_TYPE}/{OBJECT_ID}
{OBJECT_TYPE}更新するCatalog オブジェクトの種類。 有効なオブジェクトは次のとおりです。
batchesdataSetsdataSetFiles
{OBJECT_ID}リクエスト
次のリクエストでは、データセットの name フィールドと description フィールドが、ペイロードで指定された値に更新されます。 更新しないオブジェクトフィールドは、ペイロードから除外できます。
curl -X PATCH \
https://platform.adobe.io/data/foundation/catalog/dataSets/5ba9452f7de80400007fc52a \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '{
"name":"Updated Dataset Name",
"description":"Updated description for Sample Dataset"
}'
応答
リクエストが成功した場合、更新されたデータセットの ID を含む配列が返されます。 この ID は、PATCH リクエストで送信された ID と一致します。 このデータセットに対して GET リクエストを実行すると、name および description のみが更新され、他の値は変更されていないことが示されるようになりました。
[
"@/dataSets/5ba9452f7de80400007fc52a"
]
JSON パッチ表記法を使用した更新 patch-notation
次の呼び出し例は、RFC-6902 で説明されている JSON パッチを使用してオブジェクトを更新する方法を示しています。
JSON パッチ構文について詳しくは、API基本ガイド を参照してください。
API 形式
PATCH /{OBJECT_TYPE}/{OBJECT_ID}
{OBJECT_TYPE}更新するCatalog オブジェクトの種類。 有効なオブジェクトは次のとおりです。
batchesdataSetsdataSetFiles
{OBJECT_ID}リクエスト
次のリクエストでは、データセットの name フィールドと description フィールドが、各 JSON パッチオブジェクトで指定された値に更新されます。 JSON パッチを使用する場合は、Content-Type ヘッダーも application/json-patch+json に設定する必要があります。
curl -X PATCH \
https://platform.adobe.io/data/foundation/catalog/dataSets/5ba9452f7de80400007fc52a \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Content-Type: application/json-patch+json' \
-d '[
{ "op": "add", "path": "/name", "value": "New Dataset Name" },
{ "op": "add", "path": "/description", "value": "New description for dataset" }
]'
応答
リクエストが成功した場合、更新されたオブジェクトの ID を含む配列が返されます。 この ID は、PATCH リクエストで送信された ID と一致します。 このオブジェクトに対して GET リクエストを実行すると、name および description のみが更新され、他の値は変更されていないことが示されるようになりました。
[
"@/dataSets/5ba9452f7de80400007fc52a"
]
PATCH v2表記法を使用した更新 patch-v2-notation
/v2/dataSets/{DATASET_ID} エンドポイントを使用すると、複雑または詳細にネストされたデータセット属性をより柔軟に更新できます。
通常、詳細にネストされたフィールド(a.b.c.dなど)を更新する場合、パス内の各レベルが既に存在している必要があります。 任意のレベルが欠落している場合は、最終的な値を設定する前に、各レベルを手動で作成する必要があります。 多くの場合、複数の工程が必要となるため、作業が複雑化し、ミスが生じる可能性が高まります。
/v2/dataSets/{DATASET_ID} エンドポイントは、パス内に欠落しているレベルを自動的に作成します。 dを設定する前にbとcを手動で確認して追加する代わりに、PATCH v2の処理が行われます。
PATCH リクエストを/v2/dataSets/{DATASET_ID} エンドポイントに送信する場合は、最後の構造を送信するだけで済み、システムは更新を適用する前に欠落している部分を入力します。
If-MatchおよびIf-None-Match ヘッダーは、/v2/dataSets/{id} エンドポイントではオプションです。 このエンドポイントに対するPATCH リクエストは、更新を動的にマージし、最新のデータセットバージョンを取得せずに変更を行うことができます。 これにより、同時更新によるデータ損失のリスクを軽減できますが、最新のetagでIf-Matchを使用して、変更が特定のバージョンにのみ適用されるようにすることができます。 または、If-None-Matchは、データセットが最後の既知のバージョン以降に変更されていない場合、更新を防ぎます。API 形式
PATCH /V2/DATASETS/{DATASET_ID}
{DATASET_ID}リクエスト
curl -X PATCH https://platform.adobe.io/data/foundation/catalog/v2/dataSets/67b3077efa10d92ab7a71858 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Content-Type: application/json' \
-d '{
"extensions": {
"adobe_lakeHouse": {
"rowExpiration": {
"ttlValue": "P9Y"
}
}
}
}'
応答
応答が成功すると、更新されたデータセットのIDを含む配列が返されます。これは、PATCH リクエストで送信されたIDと一致する必要があります。 このオブジェクトに対してGET リクエストを実行すると、事前の手動作成手順を必要とせずにextensions.adobe_lakeHouse.rowExpiration オブジェクトが作成されたことが表示されるようになりました。
[
"@/dataSets/67b3077efa10d92ab7a71858"
]
配列フィールドの更新 array-fields
accessLabels フィールドは、データセット全体へのアクセスを制限するためにオブジェクトレベルのアクセス制御で使用されます。 データセット アクセスの評価方法について詳しくは、属性ベースのアクセス制御エンドツーエンド ガイド を参照してください。
accessLabelsなどの配列値のフィールドを置き換えるかクリアするには、PATCH リクエストに/v2/dataSets/{DATASET_ID}への完全な値を含めます。
accessLabelsの場合、エンドポイントは配列を保存する前に、各値を組織のラベルカタログに照らして検証します。 ラベルがカタログに存在しない場合、リクエストは失敗します。データセットにアクセスラベルを設定するには、データセットに含めるコアラベルとカスタムラベルをすべて含めます。
リクエスト
次のリクエストは、データセットにcore/C1とcustom/L1のアクセスラベルを設定します。
curl -X PATCH https://platform.adobe.io/data/foundation/catalog/v2/dataSets/67b3077efa10d92ab7a71858 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Content-Type: application/json' \
-d '{
"accessLabels": [
"core/C1",
"custom/L1"
]
}'
応答
応答が成功すると、更新されたデータセットのIDを含む配列が返されます。 このデータセットに対してGET リクエストを実行すると、accessLabels フィールドに更新された値が表示されるようになりました。
[
"@/dataSets/67b3077efa10d92ab7a71858"
]
配列フィールドからすべての値を削除するには、空の配列を送信します。
リクエスト
次のリクエストは、データセットのaccessLabels フィールドをクリアします。
curl -X PATCH https://platform.adobe.io/data/foundation/catalog/v2/dataSets/67b3077efa10d92ab7a71858 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Content-Type: application/json' \
-d '{
"accessLabels": []
}'
応答
応答が成功すると、更新されたデータセットのIDを含む配列が返されます。 このデータセットに対してGET リクエストを実行すると、accessLabels フィールドが空であることが表示されるようになりました。
[
"@/dataSets/67b3077efa10d92ab7a71858"
]
更新前と更新後のデータセット例
以下のJSONの例は、PATCH リクエストの before のデータセット構造を示しています。データセットにはextensions.adobe_lakeHouse.rowExpiration オブジェクトがありません。
| code language-json |
|---|
|
次のJSONは、PATCH リクエストの 後のデータセット構造 を示しています。 この更新により、手動で作成する前に、見つからないextensions.adobe_lakeHouse.rowExpiration オブジェクトが自動的に作成されます。 この例では、/v2/ PATCH リクエストで複数の操作が不要になり、更新がよりシンプルかつ効率的になる方法を示します。
| code language-json |
|---|
|