Target 管理 API の概要

この記事では、Adobe Target Admin API を正常に理解して使用するために必要な背景情報の概要を説明します。 次のコンテンツは、s の ​ 認証を設定 Adobe Target Admin API する方法を理解していることを前提としています。

始める前に

​ 管理 API に用意されているすべてのコード例で、{tenant} をテナント値に、your-bearer-token を JWT で生成するアクセストークンに、your-api-keyAdobe Developer Console​ の API キーに ​ します。 テナントと JWT について詳しくは、Adobe ​ Admin API の ​ 認証の設定 Target 方法に関する記事を参照してください。

バージョン管理

すべての API にはバージョンが関連付けられています。 使用する API の適切なバージョンを提供することが重要です。

リクエストにペイロード（POST またはPUT）が含まれる場合、リクエストの Content-Type ヘッダーを使用してバージョンを指定します。

リクエストにペイロード（GET、DELETE、OPTIONS）が含まれていない場合は、Accept ヘッダーを使用してバージョンを指定します。

バージョンが指定されていない場合、呼び出しはデフォルトで V1 （application/vnd.adobe.target.v1+json）に設定されます。

サポートされていない機能に関するエラーメッセージ

{
    "httpStatus": 406,
    "requestId": "8752b736-cf71-4d81-86c3-94be2b5ae648",
    "requestTime": "2018-02-02T21:39:06.405Z",
    "errors": [
        {
            "errorCode": "Unsupported.Feature",
            "message": "Unsupported features detected"
        }
    ]
}

Admin Postman Collection

Postmanは、API 呼び出しを簡単に実行できるアプリケーションです。 この Target 管理 API Postman コレクション ​ には、アクティビティ、オーディエンス、オファー、レポート、Mbox および環境を使用した認証を必要とするすべての Target 管理 API 呼び出しが含まれています

応答コード

Target 管理 API の一般的な応答コードを次に示します。

アクティビティ

アクティビティを使用すると、ユーザー向けにコンテンツをテストまたはパーソナライズできます。 アクティビティは、次のいずれかのタイプになります。

バッチ更新

複数の管理 API を単一のバッチリクエストとして実行できます。

呼び出しをバッチで実行

POST /{tenant}/target/batch

複数の API 呼び出しをスタックし、1 つのバッチで実行する。

バッチ処理を使用すると、1 回の HTTP リクエストで複数の操作の命令を渡すことができます。 また、関連する操作間の依存関係も指定できます（以下の節で説明します）。 TNT は、独立した各操作（場合によっては並行）を処理し、独立した操作を順番に処理します。 すべての操作が完了すると、統合応答が返され、HTTP 接続が閉じられます。

バッチ API は、JSON 配列として表された論理 HTTP リクエストの配列を取り込みます。各リクエストには、メソッド（HTTP メソッド GET/PUT/POST/DELETEなどに対応）、relativeUrl （admin/rest/の後の URL の部分）、オプションのヘッダー配列（HTTP ヘッダーに対応）、オプションの本文（POST およびPUT リクエスト用）があります。 バッチ API は、JSON 配列で表された論理 HTTP 応答の配列を返します。各応答には、ステータスコード、オプションのヘッダー配列およびオプションの本文（JSON エンコードされた文字列）が含まれます。 バッチリクエストを実行するには、実行する個々の操作を記述する JSON オブジェクトを作成します。 許可される最大操作数は 256 個（0 ～ 255）です。

リクエスト内の操作間の依存関係の指定デフォルトでは、バッチ API リクエストで指定された操作は独立しています。これらはサーバー上で任意の順序で実行でき、1 つの操作のエラーは他の操作の実行に影響を与えません。

多くの場合、リクエスト内の操作は依存します。例えば、ある操作の出力を次の操作の入力に使用できます。 例えば、operationId=0 で作成されたオファーは、キャンペーン作成 operationId=1 で使用する必要があります。

2 つのバッチ操作をリンクするには、必要な操作の ID を依存操作で指定します（例："dependsOnOperationId" : 5）。 また、バッチ操作の POST リクエストを介して作成されたリソースの ID は、「relativeUrl」と「body」の両方の依存操作で使用できます。

権限とスロットル

バッチ API アクションを実行するには、基になるユーザーは少なくとも「エディター」権限を持っている必要があります（ユーザーの権限よりも追加の権限が必要な場合は、個々の操作が失敗します）。 通常のスロットル戦略は、すべての操作が個別に実行されたかのようにバッチ API アクションに適用されます。

バッチ処理は、すべての操作が完了すると終了します。操作は、成功（2xx statusCode）、失敗（4xx、5xx ステータスコード）、または依存関係操作が失敗したかスキップされたためにスキップされます。

リクエストオブジェクトパラメーター

リクエストオブジェクトのサンプル

{
  "operations": [
    {
      "operationId": 1,
      "dependsOnOperationIds~": [0],
      "method": "POST",
      "relativeUrl": "/v1/offers",
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "body~": {
        "key": "value"
      }
    }
  ]
}

応答オブジェクトパラメーター

応答オブジェクトのサンプル

{
  "results": [
    {
      "operationId": 1,
      "skipped~": false,
      "statusCode~": 200,
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json; charset=UTF-8"
        }
      ],
      "body~": {
        "id": 5
      }
    }
  ]
}