Nozioni di base sulle API

L’obiettivo dell’API Adobe Workfront è semplificare la creazione di integrazioni con Workfront introducendo un’architettura RESTful che funziona tramite HTTP. Questo documento presuppone una familiarità con le risposte REST e JSON e descrive l’approccio adottato dall’API Workfront.

Acquisire familiarità con lo schema Workfront ti aiuterà a comprendere le relazioni tra database che possono essere utilizzate per estrarre dati da Workfront a scopo di integrazione.

Limiti e linee guida

Per garantire prestazioni coerenti del sistema Workfront on demand, l’API Workfront limita i thread API simultanei. Questo guardrail impedisce i problemi di sistema causati da chiamate API offensive. L’ambiente sandbox dispone dello stesso limite di thread API simultanei, che consente a clientela e partner di testare con precisione le chiamate API prima di rilasciare il codice in produzione.

Per gli ambienti di produzione, anteprima e test delle unità, le richieste degli utenti finali hanno una lunghezza URI massima di 8892 byte, in quanto vengono instradate tramite la rete CDN di Workfront (Akamai). Questo limite si applica solo agli URI instradati attraverso la rete CDN.

Liberatoria

Qualsiasi utilizzo dell’API deve essere testato nell’ambiente Beta di Workfront prima di essere eseguito nell’ambiente di produzione. Se un cliente utilizza l’API per un processo che Workfront ritiene ragionevolmente oneroso per il software on demand (ovvero, il processo causa un effetto sostanzialmente negativo sulle prestazioni del software per altra clientela), Workfront si riserva il diritto di richiedere che il cliente interrompa tale processo. Se il cliente non si conforma e il problema persiste, Workfront si riserva il diritto di terminare il processo.

URL API Workfront

Per informazioni sull’URL che utilizzerai per chiamare l’API Workfront, consulta Formato dominio per le chiamate API Adobe Workfront.

Nozioni di base su REST

Questa sezione fornisce un’introduzione di alto livello su come interagire con l’API REST di Workfront per i seguenti principi REST:

URI oggetto

A ogni oggetto nel sistema viene assegnato un URI univoco costituito dal tipo di oggetto e dall’ID. Gli esempi seguenti mostrano gli URI che descrivono tre oggetti univoci:

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

Il tipo di oggetto non distingue tra maiuscole e minuscole e può essere l’abbreviazione ObjCode (ad esempio proj) o il nome dell’oggetto alternativo (project).

Per un elenco di oggetti, ObjCodes validi, e campi oggetto, consulta  API Explorer.

Operazioni

Gli oggetti vengono manipolati inviando una richiesta HTTP al relativo URI univoco. L’operazione da eseguire è specificata dal metodo HTTP.

I metodi HTTP standard corrispondono alle operazioni seguenti:

Per ovviare alle carenze dei client o ai limiti di lunghezza del protocollo, il parametro di metodo può essere utilizzato per sostituire il comportamento HTTP. Ad esempio, un’operazione GET può essere implementata inserendo il seguente URI:

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

Risposta

A ogni richiesta viene fornita una risposta in formato JSON. La risposta dispone di un attributo dati se la richiesta ha avuto esito positivo o di un attributo errore se si è verificato un problema. Ad esempio, la richiesta

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

restituisce una risposta JSON simile alla seguente:

{
    "data": [
        {
            "percentComplete": 0,
            "status": "CUR",
            "priority": 2,
            "name": "Progetto appena creato",
            "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
        } 
    ] 
}

È stata aggiunta una protezione speciale per le richieste PUT, POST e DELETE. Qualsiasi richiesta che determini la scrittura o l’eliminazione dal database può essere eseguita solo se l’sessionID=abc123 è incluso nell’URI. Gli esempi seguenti mostrano come questo dovrebbe cercare una richiesta 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

Autenticazione

L’API autentica ciascuna richiesta per garantire che il client abbia accesso alla visualizzazione o alla modifica di un oggetto richiesto.

L’autenticazione viene eseguita trasmettendo un ID sessione che può essere assegnato utilizzando uno dei seguenti metodi:

Autenticazione tramite intestazione della richiesta

Il metodo preferito per l’autenticazione consiste nel trasmettere un’intestazione di richiesta denominata SessionID contenente il token di sessione. Questo presenta il vantaggio di essere progetto dagli attacchi di Cross-Site Request Forgery (CSRF, Falsificazione di richieste tra siti) e di non interferire con l’URI ai fini della memorizzazione in cache.

Di seguito è riportato un esempio di intestazione di richiesta:

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

Autenticazione basata su cookie

L’API utilizza la stessa autenticazione basata su cookie usata dall’interfaccia utente web per il sistema. In questo modo, se un client accede a Workfront utilizzando l’interfaccia utente web, tutte le chiamate AJAX effettuate all’interno dello stesso browser utilizzano la stessa autenticazione.

Accesso

Utilizzando un nome utente e una password validi, puoi utilizzare la seguente richiesta per ottenere un ID sessione:

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

Questa operazione imposta un cookie per autenticare le richieste future e restituire inoltre una risposta JSON con il sessionID appena creato, l’userID dell’utente connesso e altri attributi di sessione.

Generazione di una chiave API

Puoi generare una chiave API quando accedi al sistema come tale utente, come illustrato nell’esempio seguente:

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

Recupero di una chiave API generata in precedenza

Puoi anche recuperare una chiave API che è stata generata in precedenza per un particolare utente eseguendo getApiKey:

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

Puoi quindi utilizzare questo risultato per autenticare qualsiasi chiamata API aggiungendo “apiKey” come parametro di richiesta, in sostituzione di sessionID o di nome utente e password. Questo è vantaggioso dal punto di vista della sicurezza.

La seguente richiesta è un esempio di recupero di dati da un progetto utilizzando apiKey:

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

Annullamento della validità di una chiave API

Se il valore apiKey è stato compromesso, puoi eseguire “clearApiKey”, che invalida la chiave API corrente, come illustrato nell’esempio seguente:

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

Una volta annullata, puoi eseguire nuovamente getApiKey per generare una nuova chiave API.

Disconnessione

Al termine di una sessione, puoi utilizzare la seguente richiesta per disconnettere l’utente, impedendo qualsiasi ulteriore accesso con sessionID.

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

Il valore sessionID da disconnettere può essere specificato come cookie, intestazione di richiesta o parametro di richiesta.

Per disconnettere un utente:

Quando esegui richieste PUT, POST e DELETE, devi sempre includere l’ID sessione fornito dopo l’accesso.

Comportamento di GET

Utilizza il metodo HTTP GET per recuperare uno o più oggetti ed eseguire i rapporti.

Recupero di oggetti

Puoi migliorare la ricerca di oggetti utilizzando modificatori e filtri.

Recupero di un oggetto mediante l’ID oggetto

Se conosci l’ID di un oggetto, puoi recuperarlo accedendo al relativo URI univoco. Ad esempio, la richiesta

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

restituisce una risposta simile a quanto segue:

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

Puoi recuperare più oggetti nella stessa richiesta specificando il parametro di richiesta ID e fornendo un elenco ID separato da virgole, come mostrato nell’esempio seguente:

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

La richiesta /attask/api/v15.0/project?id=… corrisponde alla richiesta /attask/api/v15.0/project/....

Recupero di un oggetto tramite l’URI

Se desideri recuperare un oggetto in base a criteri diversi dall’ID, puoi cercare l’URI.

Ad esempio, puoi utilizzare la seguente richiesta per restituire un elenco di tutti i progetti nel sistema:

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

Puoi specificare i filtri utilizzando i parametri della richiesta come coppie nome-valore. Ad esempio, l’esempio seguente mostra una richiesta per individuare tutti i progetti correnti:

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

La richiesta seguente individua tutte le attività non ancora completate e assegnate a un utente di nome John.

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

Utilizzo dei modificatori di ricerca

Nella tabella seguente sono elencati alcuni dei modificatori che è possibile utilizzare con l’API Workfront.

…status=cls&status_Mod=eq…

…status=cls&status_Mod=ne…

…percentComplete=50&percentComplete_Mod=get…

…percentComplete=50&percentComplete_Mod=lte…

…description_Mod=isnull…

…description_Mod=notnull…

…name=Workfront&name_Mod=contains

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

Utilizzo delle istruzioni OR

Puoi migliorare una ricerca aggiungendo un parametro che includa “OR” e un numero per indicare il livello di un filtro o di una serie di filtri.

Un’istruzione OR restituisce solo i record nella chiamata API che soddisfano i criteri di filtro dell’istruzione OR. I filtri non sono impliciti tra i livelli di istruzione OR.

Ad esempio, se desideri filtrare per

quindi utilizza la seguente chiamata API con le relative istruzioni OR multiple:

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

Utilizzo dei parametri del filtro

Un potenziale problema nell’utilizzo dei parametri URL per i filtri di ricerca è che Workfront analizza alcuni parametri prima di verificare la presenza di diversi metodi di autenticazione (ad esempio nome utente, password, apiKey, cookie). In questo caso, i parametri non vengono utilizzati come filtri nella chiamata.

Per evitare questo problema, puoi inserire questi valori nei parametri del filtro con formattazione JSON. Ad esempio, se desideri filtrare in base al nome utente testuser, anziché utilizzare

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

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

Utilizzo del parametro di richiesta mappa

Per impostazione predefinita, i dati restituiti da una ricerca sono un array JSON. A seconda del caso d’uso, potrebbe essere più efficiente ottenere il risultato come oggetto JSON indicizzato per ID. Questa operazione può essere eseguita utilizzando il parametro della richiesta mappa. Ad esempio, la richiesta

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

{
    "data": {
        "4c9a97db0000000f13ee4446b9aead9b": {
            "percentComplete": 0,
            "status": "NUOVo",
            "name": "prima attività",
            "ID": "4c9a97db0000000f13ee4446b9aead9b",
            "taskNumber": 1 
        },
        "4ca28ba600002024cd49e75bd43cf601": {
            "percentComplete": 0,
            "status": "INP:A",
            "name": "seconda attività",
            "ID": "4ca28ba600002024cd49e75bd43cf601",
            "taskNumber": 2 
        } 
    } 
}

Utilizzo del parametro di richiesta campi

Per impostazione predefinita, il recupero di un oggetto restituisce solo il sottoinsieme di campi più comunemente utilizzato.

Puoi utilizzare il parametro di richiesta campi per specificare che venga restituito un elenco separato da virgole di campi specifici. Ad esempio, la richiesta

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

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

Per un elenco dei possibili riferimenti ai campi, consulta API Explorer

Ricerca di oggetti nidificati

È possibile cercare oggetti nidificati. Per impostazione predefinita, gli oggetti nidificati vengono restituiti solo con il nome e l’ID. Ad esempio, per ottenere tutti i problemi insieme ai relativi proprietari, utilizza la seguente richiesta:

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

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

{
    "name": "un problema importante",
    "ID": "4c78285f00000908ea8cfd66e084939f",
    "owner": {
        "title": "Specialista delle operazioni",
        "phoneNumber": "555-1234",
        "name": "Utente amministratore",
        "ID": "4c76ed7a0000054c172b2c2d9f7f81c3" 
    } 
}

Recupero raccolte nidificate

È possibile recuperare raccolte nidificate di oggetti. Ad esempio, per ottenere un progetto con tutte le relative attività, utilizza la seguente richiesta:

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

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

Ricerca di più campi nidificati

Per impostazione predefinita, vengono restituiti solo il nome e l’ID di ciascuna attività, ma è possibile specificare ulteriori campi nidificati con la sintassi dei due punti. Per visualizzare tutti i campi disponibili per un oggetto o una raccolta correlata, è sufficiente aggiungere due punti e un asterisco al riferimento all’oggetto o alla raccolta.

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

Recupero di dati personalizzati

Puoi recuperare campi dati personalizzati con il prefisso “DE:”. Ad esempio, per richiedere un progetto con un parametro denominato “CustomText”, utilizza la seguente richiesta:

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

{
    "name": "progetto dati personalizzati",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    "DE:CustomText": "attività 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"] 
    } 
}

Utilizzo di query denominate

Alcuni tipi di oggetto dispongono di ricerche denominate che vengono comunemente eseguite e sono disponibili aggiungendo il nome della query alla fine dell’URI del tipo di oggetto. Ad esempio, la seguente richiesta recupera gli elementi di lavoro (attività e problemi) a cui l’utente è attualmente assegnato:

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

Utilizzo di Count

Puoi utilizzare count per restituire il numero di risultati corrispondenti alla query. Questo può essere utile quando non hai bisogno dei dati nei risultati. Restituendo solo il conteggio, il server può elaborare la richiesta più rapidamente e risparmiare larghezza di banda. Ad esempio, la richiesta

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

{
    "count": 3 
}

Richiedere un rapporto

Puoi eseguire una richiesta di rapporto di cui desideri ottenere solo l’aggregato di alcuni campi con uno o più raggruppamenti. Come mostrato nell’esempio seguente, la sintassi del rapporto è la stessa della sintassi per l’API SOAP:

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

{
    "Primo progetto": { 
        "sum_hours": 15 
    }, 
     "Secondo progetto": { 
        "sum_hours": 30 
    } 
}

{
    "Primo progetto": { 
        "sum_hours": 15 
    }, 
    "Secondo progetto": { 
        "sum_hours": 30 
    }, 
    "$$ROLLUP": { 
        "sum_hours": 45 
    } 
}

Ordinamento dei risultati della query nell’API

Puoi ordinare i risultati in base a qualsiasi campo aggiungendo quanto segue alla chiamata API:

&entryDate_Sort=asc

Se ad esempio desideri ordinare in base all’attività Data inizio pianificata, rimuovi entryDate e sostituiscilo con plannedCompletionDate.

Questa operazione funziona per la maggior parte dei campi in Workfront.

Considerazione dei limiti delle query

Quando esegui una query su un oggetto, è necessario prestare particolare attenzione alla relazione tra oggetti correlati e limitazioni della ricerca. Ad esempio, come illustrato nella tabella seguente, una query per progetti può restituire non più di 2.000 progetti. Questi 2.000 progetti sono considerati “oggetti principali”. Se esegui una query per il campo Attività dei progetti, il campo Attività, che è una raccolta, diventa un oggetto secondario dell’oggetto principale Progetto. Una query per il campo Attività può includere migliaia di attività nei progetti. In totale, il numero combinato di oggetti (progetti e attività) restituiti non può superare il massimo di 50.000.

Per garantire prestazioni ottimali, la tabella seguente mostra le limitazioni imposte alle richieste di ricerca.

Utilizzo di risposte paginate using-paginated-responses

Per ignorare il limite predefinito di query per il numero di risultati e consentirne 200, puoi includere il filtro $$LIMIT=200 nella query, come illustrato nell’esempio seguente:

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

Per garantire affidabilità e prestazioni per altri tenant nel sistema, il limite massimo di risultati consentito per query è di 2.000 oggetti. Se tenti di specificare un limite maggiore, verrà visualizzato un messaggio di errore IllegalArgumentException.

Pertanto, è consigliabile considerare l’utilizzo di risposte paginate per set di dati di grandi dimensioni. Per specificare il primo risultato da restituire, aggiungi il filtro $$FIRST. Ad esempio, la seguente richiesta restituisce i risultati 201-250 per una query:

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

Nell’esempio precedente, $$FIRST=200 restituisce il 201° risultato. $$FIRST=0 restituirebbe il primo risultato. Può essere utile considerare il valore $$FIRST come il numero di risultati che desideri ignorare prima di restituire i risultati.

Per assicurarti che i risultati siano paginati correttamente, utilizza un parametro di ordinamento. Questo consente di restituire i risultati nello stesso ordine, in modo che la paginazione non ripeta né ignori dei risultati. Ad esempio, per ordinare utilizzando l’ID oggetto, utilizza ID_Sort=asc.

Creazione di una regola di accesso

Puoi creare una regola di accesso per determinare chi può accedere a un oggetto. Di seguito sono riportati alcuni esempi di regole di accesso che puoi impostare:

Per impostare un progetto in modo che venga condiviso solo con un utente con ID “abc123”, utilizza la seguente richiesta:

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/123abcxxxxxxxxxxxxxxxxxxxxxxxx?fields=accessRules:*

Comportamento delle richieste POST

La richiesta POST inserisce un nuovo oggetto. La sintassi è identica alla richiesta PUT, ma con alcune eccezioni. Poiché il nuovo oggetto non esiste ancora, non dispone di un ID. Per questo motivo, l’URI non include l’ID.

Creazione di un oggetto

Di seguito è riportato un esempio di richiesta di creazione di un nuovo progetto:

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

Copia di un oggetto

Alcuni oggetti supportano la copia. Per questi tipi di oggetto, è possibile creare nuovi oggetti pubblicandoli con un parametro copySourceID. Ad esempio, la richiesta seguente copia il progetto specificato e gli assegna un nuovo nome:

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

Caricamento di documenti

Puoi caricare i documenti tramite il seguente URL API:

POST /attask/api/v15.0/upload

{
    "handle": "4c7c08fa0000002ff924e298ee148df4"
}

POST /attask/api/v15.0/document?updates={
    name: aFileName,
    handle: abc...123, (handle ottenuto dal caricamento del file)
    docObjCode: PROJ, (o TASK, OPTASK, ecc.)
    objID: abc...123,
    currentVersion:{version:v1.0,fileName:aFileName}
}

Comportamento delle richieste PUT

Le richieste PUT vengono utilizzate per aggiornare un oggetto esistente.

La risposta per una richiesta PUT è identica a una richiesta GET. In entrambi i casi, il server restituisce il nuovo stato dell’oggetto dopo l’aggiornamento. Tutte le regole utilizzate per modificare una risposta a una richiesta GET funzionano anche con la richiesta PUT, ad esempio specificando campi aggiuntivi da restituire, dati personalizzati e così via.

Modifica di oggetti

Gli aggiornamenti agli oggetti vengono sempre eseguiti per ID utilizzando l’URI univoco dell’oggetto. I campi da aggiornare vengono specificati come parametri di richiesta. Ad esempio, per modificare il nome di un progetto puoi inviare una richiesta simile alla seguente:

PUT /attask/api/v15.0/project/4c7...?name=Nome nuovo progetto 
PUT /attask/api/v15.0/project?id=4c7..&name=Nuovo nome progetto

Specificare le modifiche JSON

Come mostrato nell’esempio seguente, puoi utilizzare il parametro della richiesta degli aggiornamenti per specificare i campi da aggiornare utilizzando la sintassi JSON:

PUT /attask/api/v15.0/project/4c7...?updates= 
{
     nome: "Nuovo nome progetto", 
     stato: "CUR", 
     ... 

Esecuzione di aggiornamenti nidificati

Alcuni oggetti dispongono di raccolte private che possono essere aggiornate. Nell’esempio seguente viene illustrato come sovrascrivere le assegnazioni esistenti per una determinata attività:

PUT /attask/api/v15.0/task/4c7...?updates= 
{
    assegnazioni: [ 
        { 
            assignedToID: "2222...54d0, 
            assignmentPercent: 50,0 
        },{ 
            roleID: "1111...54d0"
        } 
    ] 

Nell’esempio seguente un progetto diventa una coda pubblica dell’help-desk. Le proprietà della coda esistenti vengono sostituite.

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

Utilizzo del parametro della richiesta di azione

Alcuni oggetti supportano azioni aggiuntive che possono essere eseguite in aggiunta a semplici modifiche. Puoi specificare queste azioni utilizzando il parametro della richiesta di azione. Ad esempio, la richiesta seguente ricalcola la timeline per un determinato progetto:

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

or

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

Spostare gli di oggetti

Di seguito viene illustrata la sintassi per lo spostamento di un’attività da un progetto a un altro:

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

Di seguito è riportato un esempio di ciascun tipo di azione:

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

Condividere di oggetti

L’esempio seguente illustra la sintassi per la condivisione di un progetto con un team:

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..

Comportamento del metodo DELETE

Il metodo DELETE rimuove un oggetto. In tutti i casi, l’URI può includere il parametro force=true per fare in modo che il server rimuova i dati specificati e le relative dipendenze. Nell’esempio seguente, un’attività viene eliminata eseguendo il metodo HTTP DELETE su un URI:

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

Aggiornamenti in blocco

Un’istruzione di aggiornamento in blocco aggiorna più oggetti contemporaneamente all’interno di una singola chiamata API. Una chiamata API per la creazione in blocco viene generata in modo simile a una normale chiamata di aggiornamento, come mostrato negli esempi seguenti:

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",
     nome: "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",
    priorità: 0,
    projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
    status: "CUR"
}]