API の基本

Last update: Fri Apr 24 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

トピック：

作成対象：

開発者

Adobe Workfront API の目的は、HTTP 経由で動作する REST フルアーキテクチャを導入することで、Workfront との統合の構築を簡略化することです。このドキュメントでは、REST および JSON の応答に精通していることを前提とし、Workfront API で採用されているアプローチについて説明します。

Workfront スキーマに精通していれば、統合のために Workfront からデータを取り出すときに使用できるデータベースの関係を理解できます。

制限とガイドライン

Workfront のオンデマンドシステムでの一貫したパフォーマンスの確保に、Workfront API では同時 API スレッドを制限しています。このガードレールは、不正な API 呼び出しに起因するシステムの問題を防ぎます。サンドボックス環境にも同時 API スレッド制限があるので、お客様とパートナーは、コードを実稼動環境にリリースする前に API 呼び出しを正確にテストできます。

実稼動、プレビューおよび体験版の環境では、エンドユーザーのリクエストは Workfront CDN（Akamai）を介してルーティングされるので、URI の最大長は 8892 バイトとなります。この制限は、CDN 経由でルーティングされる URI にのみ適用されます。

免責事項

API の使用は、本番環境で実行する前に、Workfront Beta 環境でテストする必要があります。お客様がオンデマンドのソフトウェアに負担をかけると合理的に判断する処理で API を使用している場合（当該処理が他のお客様のソフトウェアのパフォーマンスに重大な悪影響を及ぼしている場合）、Workfront は当該処理の中止をお客様に求める権利を有します。お客様がこれに応じず問題が継続する場合、Workfront は当該処理を終了させる権利を有します。

Workfront API の URL

Workfront API を呼び出すために使用する URL について詳しくは、Adobe Workfront API 呼び出しのドメイン形式を参照してください。

REST の基本

この節では、次の REST 原則に関して、Workfront REST API とやり取りを行う方法を詳しく説明します。

オブジェクト URI

システム内の各オブジェクトには、オブジェクトタイプと ID で構成される一意の URI が与えられます。次の例は、3 つの一意のオブジェクトを記述する URI を示しています。

/attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0
/attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d1
/attask/api/v15.0/issue/4c78821c0000d6fa8d5e52f07a1d54d2

オブジェクトタイプは大文字と小文字が区別されず、省略形の ObjCode（proj など）、または代替オブジェクト名（project など）を指定できます。

オブジェクト、有効な ObjCodes およびオブジェクトフィールドのリストについて詳しくは、API エクスプローラーを参照してください。

NOTE

Workfront API のコンテキストでは、カスタムフォームは Category オブジェクトであり、カスタムフィールドは Parameter オブジェクトです。

操作

オブジェクトは、一意の URI に HTTP リクエストを送信して操作します。実行する操作は、HTTP メソッドで指定します。

標準の HTTP メソッドは、次の操作に対応しています。

GET - ID でオブジェクトを取得、クエリですべてのオブジェクトを検索、レポートを実行、名前付きクエリを実行
POST - 新しいオブジェクトを挿入
PUT - 既存のオブジェクトを編集
DELETE - オブジェクトを削除

クライアントの問題やプロトコルの長さ制限を回避するために、メソッドパラメーターを使用して HTTP の動作を上書きできます。例えば、GET 操作は、次の URI を送信することで実装できます。

GET /attask/api/v15.0/project?id=4c78...54d0&method=get
GET /attask/api/v15.0/project/4c78...54d0?method=get

応答

各リクエストには、JSON 形式での応答が返されます。リクエストが成功した場合はデータ属性が応答に含まれ、問題が発生した場合はエラー属性が含まれます。例えば、次のリクエスト：

GET /attask/api/v15.0/proj/4c7c08b20000002de5ca1ebc19edf2d5

これは、次のような JSON 応答を返します。

{
    "data": [
        {
            "percentComplete": 0,
            "status": "CUR",
            "priority": 2,
            "name": "Brand New Project",
            "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
        } 
    ] 
}

NOTE

ブラウザーのアドレスバーから GET リクエストを実行する場合、sessionID をリクエストの一部に含める必要はありません。

PUT、POST、DELETE の各リクエストに対する特別なセキュリティが追加されました。データベースへの書き込みまたはデータベースからの削除が発生するリクエストは、 sessionID=abc123 が URI に含まれている場合のみ実行できます。次に示すのは、DELETE リクエストでの例です。

GET /attask/api/v15.0/project?id=4c78...54d0&method=delete&sessionID=abc123
GET /attask/api/v15.0/project/4c78...54d0?method=delete&sessionID=abc123

認証

API はリクエストごとに認証を行い、リクエストされたオブジェクトを表示または変更するためのアクセス権をクライアントが持っていることを確認します。

認証は、次のいずれかの方法で与えられるセッション ID を渡すことで実行されます。

リクエストヘッダー認証

推奨される認証方法は、セッショントークンを含む SessionID という名前のリクエストヘッダーを渡すことです。クロスサイトリクエストフォージェリー（CSRF）攻撃に対して安全で、キャッシュ目的で URI に干渉することがありません。

リクエストヘッダーの例を次に示します。

GET /attask/api/v15.0/project/search
SessionID: abc1234

API は、Web UI でシステムに使用されるのと同じ Cookie ベースの認証を使用します。ここで、クライアントが Web UI を使用して Workfront にログインした場合、同じブラウザー内で行われる AJAX 呼び出しに同じ認証を使用します。

NOTE

CSRF（クロスサイトリクエストフォージェリー）攻撃の可能性から保護するために、この認証方法は読み取り専用操作でのみ使用できます。

この節で説明する手順は、Adobe Business Platformにオンボーディングされていない組織にのみ適用されます。すべての組織がAdobe Business Platformにオンボーディングされたため、Workfront APIを使用してWorkfrontにログインできなくなります。

お客様の組織がAdobe Workfront Business Platformにオンボーディングされているかどうかに応じて異なる手順の一覧については、AdobeとAdobe Business Platformの管理の違いを参照してください。

有効なユーザー名とパスワードを使用すると、次のリクエストを使用してセッション ID を取得できます。

POST /attask/api/v15.0/login?username=admin&password=user

これにより、今後のリクエストを認証する Cookie が設定され、新しく作成された sessionID、ログインしたユーザーの userID、その他のセッション属性を含む JSON 応答が返されます。

NOTE

管理者でもある API ユーザーが指定されている場合、Workfront では、ログインに API キーを使用することを強くお勧めします。

API キーの生成

次の例に示すユーザーとしてシステムにログインすると、API キーを生成できます。

PUT /attask/api/v15.0/user?action=generateApiKey&username= username&password=password&method=put

以前に生成した API キーの取得

また、getApiKey を実行すると、特定のユーザー用に以前に生成された API キーを取得することもできます。

PUT /attask/api/v15.0/user?action=getApiKey&username=user@email.com&password=userspassword&method=put

その後、sessionID またはユーザー名とパスワードの代わりにこの値を含むリクエストパラメーターとして「apiKey」を追加することで、この結果を使用して API 呼び出しを認証できます。これは、セキュリティの観点から有益です。

次に、apiKey を使用してプロジェクトからデータを取得するリクエストの例を示します。

GET /attask/api/v15.0/project/abc123xxxxx?apiKey=123abcxxxxxxxxx

API キーの無効化

apiKey 値が侵害された場合は、次の例に示すように、「clearApiKey」を実行して、現在の API キーを無効にすることができます。

GET /attask/api/v15.0/user?action=clearApiKey&username=user@email.com&password=userspassword&method=put

クリアすると、getApiKey を再度実行して新しい API キーを生成できます。

ログアウト

セッションが完了したら、次のリクエストを使用してユーザーをログアウトし、sessionID でのアクセスを防止します。

GET /attask/api/v15.0/logout?sessionID=abc1234

ログアウトする sessionID は、Cookie、リクエストヘッダーまたはリクエストパラメーターのいずれかとして指定できます。

ユーザーをログアウトするには、下記の手順に従います。

ログイン画面に移動しますが、ログインはしないでください。
URL を/attask/api/v15.0/project/search に変更します。
ページが見つからないことに注意してください。
search という単語を login?username=admin&password=user に置き換え、admin と *user を自分のユーザー名とパスワードに置き換えます。
*このセッションはブラウザーに cookie として保存されるので、後続の GET リクエストのたびに再記述する必要はありません。
URL を /attask/api/v15.0/project/search に戻します。
提供された応答に注意してください。

PUT、POST、DELETE の各リクエストを実行する際は、ログイン後に提供される sessionID を常に含める必要があります。

GET 動作

1 つ以上のオブジェクトを取得し、レポートを実行するには、HTTP GET メソッドを使用します。

オブジェクトの取得

修飾子とフィルターを使用すると、オブジェクトの検索を強化できます。

オブジェクト ID を使用したオブジェクトの取得

オブジェクトの ID がわかっている場合は、その一意の URI にアクセスしてオブジェクトを取得できます。例えば、次のリクエスト：

GET /attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0

は、次のような応答を返します。

{
    "percentComplete": 0,
    "status": "CUR",
    "priority": 2,
    "name": "Brand New Project",
    "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
}

次の例に示すように、同じリクエストで複数のオブジェクトを取得するには、ID リクエストパラメーターを指定し、ID のコンマ区切りリストを指定します。

GET /attask/api/v15.0/project?id=4c78...54d0,4c78...54d1

/attask/api/v15.0/project?id=…リクエストは /attask/api/v15.0/project/... リクエストと同じであることに留意してください。

URI を使用したオブジェクトの取得

ID 以外の条件でオブジェクトを取得する場合は、URI を検索できます。

例えば、次のリクエストを使用して、システム内のすべてのプロジェクトのリストを返すことができます。

GET /attask/api/v15.0/project/search

リクエストパラメーターを名前と値のペアとして使用して、フィルターを指定できます。例えば、次の例は、現在のすべてのプロジェクトを検索するリクエストを示しています。

GET /attask/api/v15.0/project/search?status=CUR

次のリクエストでは、John というユーザーに割り当てられているすべての未完了のタスクを検索します。

GET /attask/api/v15.0/task/search?percentComplete=100
&percentComplete_Mod=lt &assignedTo:firstName=John

検索修飾子の使用

次の表に、Workfront API で使用できる修飾子の一部を示します。

修飾子

説明

例

クローズ済みのステータスの結果を返す

…status=cls&status_Mod=eq…

クローズ済みのステータスではない結果を返す

…status=cls&status_Mod=ne…

gte

完了率が 50 以上の結果を返す

…percentComplete=50&percentComplete_Mod=gte…

lte

完了率が 50 以下の結果を返す

…percentComplete=50&percentComplete_Mod=lte…

isnull

説明が Null の結果を返す

…description_Mod=isnull…

notnull

説明が Null でない結果を返す

…description_Mod=notnull…

contains

名前に「Workfront」が含まれる結果を返す

…name=Workfront&name_Mod=contains…

between

過去 7 日以内のエントリ日を持つ結果を返す

…entryDate=$$TODAY-7d&entryDate_Range=$$TODAY&entryDate_Mod=between…

NOTE

検索リクエストでは、大文字と小文字が区別されます。エラーが発生した場合は、_Mod および _Range の大文字と小文字が正しいことを確認してください。

OR ステートメントの使用

「OR」を含むパラメーターと数値を追加して検索を拡張し、1 つのフィルターまたは一連のフィルターのレベルを示すことができます。

OR ステートメントは、OR ステートメントのフィルタリング条件を満たす API 呼び出しのレコードのみを返します。フィルターは、OR ステートメントのレベル全体に暗黙的に適用されません。

例えば、次のようなフィルターを実行する場合：

「Planning」を含む名前を持つタスク OR
「FixedAssets」という名前のポートフォリオ内のタスク AND 「Steve」を含む名前のユーザーに割り当てられている OR
「最終タスク」という名前の親タスクを持つタスク

次のように、複数の OR ステートメントを持つ API 呼び出しを使用します。

GET /attask/api/v15.0/task/search?name=Planning
&name_Mod=contains
&OR:1:portfolio:name=FixedAssets
&OR:1:portfolio:name_Mod=eq
&OR:1:assignedTo:name=Steve
&OR:1:assignedTo:name_Mod=cicontains
&OR:2:parent:name=Final Task
&OR:2:parent:name_Mod=eq

フィルターパラメーターの使用

検索フィルターに URL パラメーターを使用する際に陥りそうな問題の 1 つは、Workfront が特定のパラメーターを解析してから、様々な認証方法（ユーザー名、パスワード、apiKey、cookie）を確認することです。この場合、パラメーターは呼び出しでフィルターとして使用されません。

この問題を回避するには、JSON 形式のフィルターパラメーターにこれらの値を配置します。例えば、以下を使用する代わりに、ユーザー名 testuser にフィルタリングを行う場合

/attask/api/v15.0/user/search?username=testuser@workfront.com

/attask/api/v15.0/user/search?filters={"username":"testuser@workfront.com"}

マップリクエストパラメーターの使用

デフォルトでは、検索から返されるデータは JSON 配列です。ユースケースによっては、ID でインデックス付けされた JSON オブジェクトとして結果を取得するほうが効率的な場合があります。これは、map リクエストパラメーターを使用して行うことができます。例えば、次のリクエスト：

/attask/api/v15.0/task/search?map=true

{
    "data": {
        "4c9a97db0000000f13ee4446b9aead9b": {
            "percentComplete": 0,
            "status": "NEW",
            "name": "first task",
            "ID": "4c9a97db0000000f13ee4446b9aead9b",
            "taskNumber": 1 
        },
        "4ca28ba600002024cd49e75bd43cf601": {
            "percentComplete": 0,
            "status": "INP:A",
            "name": "second task",
            "ID": "4ca28ba600002024cd49e75bd43cf601",
            "taskNumber": 2 
        } 
    } 
}

フィールドリクエストパラメーターの使用

デフォルトでは、オブジェクトを取得すると、最も一般的に使用されるフィールドのサブセットのみが返されます。

フィールドリクエストパラメーターを使用して、特定のフィールドのカンマ区切りのリストが返されることを指定できます。例えば、次のリクエスト：

/attask/api/v15.0/task/search?fields=plannedStartDate,priority

{
    "priority": 2,
    "name": "first task",
    "ID": "4c7c08fa0000002ff924e298ee148df4",
    "plannedStartDate": "2010-08-30T09:00:00:000-0600" 
}

NOTE

これらのフィールド名では、大文字と小文字が区別されます。

使用可能なフィールド参照のリストについては、API エクスプローラーを参照してください。

ネストされたオブジェクトの検索

ネストされたオブジェクトを検索できます。デフォルトでは、ネストされたオブジェクトは名前と ID のみで返されます。例えば、すべてのイシューを所有者とともに取得するには、次のリクエストを使用します。

/attask/api/v15.0/issue/search?fields=owner

/attask/api/v15.0/issue/search?fields=owner:title,owner:phoneNumber

{
    "name": "an important issue",
    "ID": "4c78285f00000908ea8cfd66e084939f",
    "owner": {
        "title": "Operations Specialist",
        "phoneNumber": "555-1234",
        "name": "Admin User",
        "ID": "4c76ed7a0000054c172b2c2d9f7f81c3" 
    } 
}

ネストされたコレクションの取得

オブジェクトのネストされたコレクションを取得できます。例えば、すべてのタスクを含むプロジェクトを取得するには、次のリクエストを使用します。

/attask/api/v15.0/project/search?fields=tasks

/attask/api/v15.0/task/search?fields=assignments

複数のネストされたフィールドの検索

デフォルトでは、各タスクの名前と ID のみが返されますが、追加のネストされたフィールドはコロン構文で指定できます。関連するオブジェクトまたはコレクションの使用可能なすべてのフィールドを表示するには、単にコロンとアスタリスクをオブジェクトまたはコレクション参照に追加します。

/attask/api/v15.0/task/search?fields=assignments:*

カスタムデータの取得

接頭辞「DE:」を使用して、カスタムデータフィールドを取得できます。例えば、「CustomText」というパラメーターを持つプロジェクトをリクエストするには、次のリクエストを使用します。

/attask/api/v15.0/project/search?fields=DE:CustomText

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    "DE:CustomText": "task b" 
}

/attask/api/v15.0/project/search?fields=parameterValues

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    parameterValues: { 
        "DE:CustomText": "task b", 
        "DE:CustomNumber": 1.4, 
        "DE:CustomCheckBoxes": ["first", "second", "third"] 
    } 
}

名前付きクエリの使用

一部のオブジェクトタイプには、一般的に実行される名前付き検索があり、クエリの名前をオブジェクトタイプ URI の末尾に追加することで使用できます。例えば、次のリクエストでは、ユーザーに現在割り当てられている作業アイテム（タスクとイシュー）を取得します。

/attask/api/v15.0/work/myWork

`Count` の使用

count を使用して、クエリに一致する結果の数を返します。これは、結果にデータが必要ない場合に役立ちます。カウントのみを返すことで、サーバーはリクエストをより迅速に処理し、帯域幅を節約できます。例えば、次のリクエスト：

GET /attask/api/v15.0/project/count?status=CUR

{
    "count": 3 
}

レポートのリクエスト

1 つ以上のグループ化がある場合、一部のフィールドの集計のみが必要なレポートリクエストを実行できます。次の例に示すように、レポートの構文は SOAP API の構文と同じです。

GET /attask/api/v15.0/hour/report?project:name_1_GroupBy=true&hours_AggFunc=sum

{
    "First Project": { 
        "sum_hours": 15 
    }, 
     "Second Project": { 
        "sum_hours": 30 
    } 
}

{
    "First Project": { 
        "sum_hours": 15 
    }, 
    "Second Project": { 
        "sum_hours": 30 
    }, 
    "$$ROLLUP": { 
        "sum_hours": 45 
    } 
}

API でのクエリ結果の並べ替え

API 呼び出しに以下を追加すると、任意のフィールド別に結果を並べ替えることができます。

&entryDate_Sort=asc

たとえば、タスクの予定開始日で並べ替える場合は、entryDate を削除し、plannedCompletionDate に置き換えます。

これは、Workfront のほとんどのフィールドで使用できます。

クエリ制限の検討

オブジェクトのクエリを実行する場合は、関連するオブジェクトの関係と検索制限に関して特に考慮する必要があります。例えば、次の表に示すように、プロジェクトのクエリで返されるプロジェクト数は 2,000 以下です。これら 2,000 個のプロジェクトが「プライマリオブジェクト」と見なされます。プロジェクトのタスクフィールドに対してクエリを実行すると、タスクフィールド（コレクション）は、プライマリオブジェクトであるプロジェクトのセカンダリオブジェクトになります。タスクフィールドのクエリには、プロジェクト上の何千ものタスクを含めることができます。返されるオブジェクト（プロジェクトとタスク）の合計数は、全体で最大値の 50,000 個を超えることはできません。

最適なパフォーマンスを実現するために検索リクエストに設けられた制限を、次の表に示します。

クエリ結果

制限事項

説明

デフォルトの結果の数

100

クエリフィルター ($$LIMIT) で制限が指定されていない場合、結果に含めることができるプライマリオブジェクトは 100 個までです。
この制限を変更する方法について詳しくは、ページ分割された応答の使用を参照してください。

結果の最大数

2,000

クエリフィルター（例：$$LIMIT）は、2000 件までの結果を返すことができます。詳しくは、「ページ分割された応答」を参照してください。

最大フィールド深度

表示するフィールドを識別する場合、クエリ対象のオブジェクトから離れられるのは 4 レベルまでです。

オブジェクトの最大数

50,000

結果セットには、プライマリオブジェクトとセカンダリオブジェクトを 50000 個含めることはできません。

フィールドの最大数

1,000,000

結果セットに含まれるオブジェクトが 50000 個未満の場合、結果に含まれるフィールドの数は最大 1,000,000 個です。

バッチの作成や更新の最大数

100

バッチの作成または更新の上限は 100 です。

ページ分割された応答の使用 using-paginated-responses

デフォルトの結果数のクエリの制限を上書きし、200 個の結果を許可するには、次の例に示すように、クエリに $$LIMIT=200 フィルターを指定します。

GET/attask/api/v15.0/project/search?$$LIMIT=200

システム内の他のテナントに対する信頼性とパフォーマンスを確保するために、1 つのクエリに許可される結果の最大数は 2,000 個のオブジェクトです。制限を大きく指定しようとすると、IllegalArgumentException エラーメッセージが表示されます。

したがって、大きなデータセットに対して、ページ分割された応答の使用を検討することをお勧めします。返される最初の結果を指定するには、$$FIRST フィルターを追加します。例えば、次のリクエストは、クエリの結果 201-250 を返します。

GET /attask/api/v15.0/project/search?$$FIRST=200&$$LIMIT=50

上記の例では、$$FIRST=200 は 201 番目の結果を返します。 $$FIRST=0 は最初の結果を返します。 $$FIRST の値は、結果を返す前にスキップする結果の数と考えると役立つ場合があります。

結果が正しくページ分割されるようにするには、並べ替えパラメーターを使用します。これにより、結果が同じ順序で返されるので、ページネーションは結果を繰り返したりスキップしたりしません。例えば、オブジェクト ID を使用して並べ替えるには、「ID_Sort=asc」を使用します。

アクセスルールの作成

アクセスルールを作成して、オブジェクトにアクセスできるユーザーを決定できます。次に、設定できるアクセスルールの例を示します。

ID が「abc123」のユーザーとのみ共有されるようにプロジェクトを設定するには、次のリクエストを使用します。

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=put &updates={ accessRules: [ {accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'} ] }

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?method=put&accessorID=abc123&accessorObjCode=USER&coreAction=VIEW

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?fields=accessRules:*

POST 動作

POST は、新しいオブジェクトを挿入します。構文は「PUT」と同じですが、いくつかの例外があります。新しいオブジェクトはまだ存在しないので、ID は付いていません。このため、URI には ID が含まれません。

オブジェクトの作成

次に、新しいプロジェクトを作成するリクエストの例を示します。

POST /attask/api/v15.0/project?name=New Project

オブジェクトのコピー

一部のオブジェクトは、コピーをサポートしています。これらのオブジェクトタイプでは、copySourceID パラメーターを使用して投稿することで、新しいオブジェクトを作成できます。例えば、次のリクエストは、指定されたプロジェクトをコピーし、新しい名前を付けます。

POST /attask/api/v15.0/project?copySourceID=4c7...&name=Copied Project

ドキュメントのアップロード

次の API URL を使用してドキュメントをアップロードできます。

POST /attask/api/v15.0/upload

{
    "handle": "4c7c08fa0000002ff924e298ee148df4"
}

POST /attask/api/v15.0/document?updates={
    name: aFileName,
    handle: abc...123, (handle from the file upload)
    docObjCode: PROJ, (or TASK, OPTASK, etc)
    objID: abc...123,
    currentVersion:{version:v1.0,fileName:aFileName}
}

PUT 動作

PUT は、既存のオブジェクトの更新に使用されます。

PUT に対する応答は GET と同じです。どちらの場合も、サーバーは更新後にオブジェクトの新しい状態を返します。 GET リクエストへの応答を変更するために使用されるすべてのルールは、PUT と連携しても機能します。例えば、返される追加のフィールドやカスタムデータを指定するなどです。

オブジェクトの編集

オブジェクトの更新は、常に、オブジェクトの一意の URI を使用して ID で行われます。更新するフィールドは、リクエストパラメーターとして指定します。例えば、プロジェクトの名前を変更するには、次のようなリクエストを送信します。

PUT /attask/api/v15.0/project/4c7...?name=新しいプロジェクト名
PUT /attask/api/v15.0/project?id=4c7...&name=新しいプロジェクト名

JSON 編集の指定

次の例に示すように、updates リクエストパラメーターを使用して、JSON 構文を使用して更新するフィールドを指定できます。

PUT /attask/api/v15.0/project/4c7...?updates= 
{
     名前：「新しいプロジェクト名」、
     ステータス：「CUR」、
     ... 
}

ネストされた更新の作成

一部のオブジェクトには、非公開で所有するコレクションを更新できます。例えば、次の例は、特定のタスクの既存の割り当てを上書きする方法を示しています。

PUT /attask/api/v15.0/task/4c7...?updates= 
{
    割り当て：[
        { 
            assignedToID: "2222...54d0, 
            assignmentPercent: 50.0 
        },{ 
            roleID: "1111...54d0"
        } 
    ]

NOTE

最上位レベルに対する更新は少ないものの、コレクションまたはネストされたオブジェクトに対する更新は既存のコレクションを完全に置き換えます。オブジェクトに影響を与えずにタスクに対する 1 つの割り当てを編集するには、タスクに対する PUT ではなく、割り当てに対するタスクを使用します。

次の例では、プロジェクトをパブリックヘルプデスクキューにします。既存のキューのプロパティは置き換えられます。

PUT /attask/api/v15.0/project/4c7...?updates= 
{ 
    queueDef: { 
        isPublic: 1 
    }

アクションリクエストパラメーターの使用

一部のオブジェクトは、単純な編集に加えて、追加のアクションをサポートしています。これらのアクションは、アクションリクエストパラメーターを使用して指定できます。例えば、次のリクエストでは、指定されたプロジェクトのタイムラインが再計算されます。

PUT /attask/api/v15.0/project/4c7...?action=calculateTimeline

または

PUT /attask/api/v15.0/project/4c7.../calculateTimeline

オブジェクトの移動

次の例は、あるプロジェクトから別のプロジェクトにタスクを移動する際の構文を示しています。

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

PUT /attask/api/v15.0/project/1234/approveApproval

PUT /attask/api/v15.0/project/1234/calculateFinance

PUT /attask/api/v15.0/project/1234/calculateTimeline

PUT /attask/api/v15.0/project/1234/calculateDataExtension

PUT /attask/api/v15.0/project/1234/recallApproval

PUT /attask/api/v15.0/project/1234/rejectApproval

PUT /attask/api/v15.0/task/1234/move

PUT /attask/api/v15.0/workitem/1234/markViewed

各アクションタイプの例を次に示します。

PUT /attask/api/v15.0/project/1234?method=put&updates={accessRules:[{accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'}]}

オブジェクトの共有

次の例は、プロジェクトをチームと共有するための構文を示しています。

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?accessorID=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx&accessorObjCode=TEAMOB

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=PUT&updates={accessRules:[{accessorID:'123abcxxxxxxxxxxxxxxxxxxxxxxxxxx',accessorObjCode:'TEAMOB',coreAction:'VIEW'}]}

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

DELETE 動作

DELETE はオブジェクトを削除します。いずれの場合も、URI にパラメーター force=true を含めると、サーバーは指定したデータとその依存関係を削除します。次の例では、URI に対して HTTP DELETE メソッドを実行してタスクを削除します。

DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0?force=true 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0?force=true

一括更新

一括更新ステートメントは、1 回の API 呼び出し内で複数のオブジェクトを同時に更新します。一括作成 API 呼び出しは、次の例に示すように、通常の更新呼び出しと同様に作成されます。

PUT /attask/api/v15.0/proj?updates=[{"name":"Test_Project_1"},{"name":"Test_Project_2"}]&method=POST&apiKey=123ab-cxxxxxxxxxxxxxxxxxxxxxxxxxx

PUSH /attask/api/v15.0/proj?updates=[{"name":"Test_Project_1"},{"name":"Test_Project_2"}]&method=POST&apiKey=123ab-cxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [{
    ID: "53ff8d3d003b438b57a8a784df38f6b3",
    name: "Test_Project_1",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
},
{
    ID: "53ff8d49003b43a2562aa34eea3b6b10",
    name: "Test_Project_2",
    objCode: "PROJ",
    percentComplete: 0usi,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
}]

PUT /attask/api/v15.0/proj?Umethod=PUT&updates=[{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_1_ Edit"},{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_2_Edit"}]&apiKey=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [ {
     ID: "53ff8e15003b461d4560f7f65a440078",
     name: "Test_Project_1_Edit",
     objCode: "PROJ",
     percentComplete: 0,
     plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
     plannedStartDate: "2014-08-28T11:00:00:000-0400",
     priority: 0,
     projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
     status: "CUR"
},
{
    ID: "53ff8e19003b46238a58d303608de502",
    name: "Test_Project_2_Edit",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
    status: "CUR"
}]

NOTE

アトミックバッチ操作は、「success: true」またはエラーのみを返すことができます。

recommendation-more-help

5f00cc6b-2202-40d6-bcd0-3ee0c2316b43

API の基本

制限とガイドライン

免責事項

Workfront API の URL

REST の基本

オブジェクト URI

操作

応答

認証

リクエストヘッダー認証

Cookie ベースの認証

ログイン

ログアウト

GET 動作

オブジェクトの取得

オブジェクト ID を使用したオブジェクトの取得

URI を使用したオブジェクトの取得

検索修飾子の使用

OR ステートメントの使用

フィルターパラメーターの使用

マップリクエストパラメーターの使用

フィールドリクエストパラメーターの使用

ネストされたオブジェクトの検索

ネストされたコレクションの取得

複数のネストされたフィールドの検索

カスタムデータの取得

名前付きクエリの使用

Count の使用

レポートのリクエスト

API でのクエリ結果の並べ替え

クエリ制限の検討

ページ分割された応答の使用 using-paginated-responses

アクセスルールの作成

POST 動作

オブジェクトの作成

オブジェクトのコピー

ドキュメントのアップロード

PUT 動作

オブジェクトの編集

JSON 編集の指定

ネストされた更新の作成

アクションリクエストパラメーターの使用

オブジェクトの移動

オブジェクトの共有

DELETE 動作

一括更新

`Count` の使用