Grunderna i API

Senast uppdaterad: 5 maj 2025
  • Ämnen:

Skapat för:

  • Utvecklare

Målet för Adobe Workfront API är att förenkla byggintegreringen med Workfront genom att införa en REST-full arkitektur som fungerar över HTTP. I det här dokumentet förutsätts att du känner till REST- och JSON-svar och beskriver hur Workfront API fungerar.

Tack vare att du känner till Workfront-schemat kan du förstå de databasrelationer som kan användas för att hämta data från Workfront i integrationssyfte.

Begränsningar och riktlinjer

För att Workfront on demand-system ska fungera på ett konsekvent sätt begränsar Workfront API-trådar samtidigt. Detta skyddsräcke förhindrar systemproblem som orsakas av felaktiga API-anrop. Sandlådemiljön har samma samtidiga API-trådgräns, vilket gör att kunder och partner kan testa API-anrop korrekt innan kod släpps i produktionen.

I produktions-, förhandsgransknings- och testmiljöer har slutanvändarförfrågningar en maximal URI-längd på 8 892 byte eftersom de dirigeras via Workfront CDN (Akamai). Denna gräns gäller endast URI:er som dirigeras genom CDN.

Ansvarsfriskrivning

All användning av API:t bör testas i Workfront beta-miljö innan den körs i produktionsmiljön. Om någon kund använder API för en process som Workfront rimligen anser vara betungande för on-demand-programvaran (dvs. processen orsakar en i hög grad negativ effekt på programvarans prestanda för andra kunder), förbehåller sig Workfront rätten att begära att kunden avbryter denna process. Om kunden inte rättar sig efter detta och problemet kvarstår förbehåller sig Workfront rätten att avsluta processen.

Workfront API-URL

Mer information om den URL som du kommer att använda för att anropa Workfront API finns i Domänformat för Adobe Workfront API-anrop.

Grundläggande om REST

I det här avsnittet ges en introduktion på hög nivå om hur du interagerar med Workfront REST API för följande REST-principer:

Objekt-URI

Varje objekt i systemet får en unik URI som består av objekttypen och ID:t. I följande exempel visas URI:er som beskriver tre unika objekt:

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

Objekttypen är skiftlägeskänslig och kan vara antingen den förkortade ObjCode (till exempel proj) eller det alternativa objektnamnet (projekt).

En lista över objekt, giltiga ObjCodes-fält och objektfält finns på  API Explorer.

OBSERVERA
I Workfront API är ett anpassat formulär ett Category-objekt och ett anpassat fält är ett Parameter-objekt.

Operationer

Objekten ändras genom att en HTTP-begäran skickas till deras unika URI. Den åtgärd som ska utföras anges av HTTP-metoden.

Standardmetoderna för HTTP motsvarar följande åtgärder:

  • GET - Hämtar ett objekt efter ID, söker efter alla objekt efter en fråga, kör rapporter eller kör namngivna frågor
  • POST - Infogar ett nytt objekt
  • PUT - Redigerar ett befintligt objekt
  • DELETE - Tar bort ett objekt

För att undvika klientbrister eller protokolllängdsbegränsningar kan parametern method användas för att åsidosätta HTTP-beteendet. En GET-åtgärd kan till exempel implementeras genom följande URI:

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

Svar

Varje begäran besvaras i JSON-format. Svaret har antingen ett dataattribut om begäran lyckades eller ett felattribut om ett problem uppstod. Till exempel begäran

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

returnerar ett JSON-svar som liknar följande:

{
}    "data": [
        {
            "percentComplete": 0,
            "status": "CUR",
            "priority": 2,
            "name": "Brand New Project",
            "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
        } 
    ]
OBSERVERA
När du kör en GET-begäran via webbläsarens adressfält behöver du inte inkludera sessions-ID som en del av begäran.

Särskild säkerhet har lagts till runt förfrågningar från PUT, POST och DELETE. Alla förfrågningar som resulterar i att data skrivs till eller tas bort från databasen kan bara köras om sessionID=abc123 ingår i URI:n. I följande exempel visas hur detta skulle söka efter en DELETE-begäran:

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

Autentisering

API:t autentiserar varje begäran för att säkerställa att klienten har åtkomst att visa eller ändra ett begärt objekt.

Autentisering utförs genom att ett sessions-ID skickas som kan ges på något av följande sätt:

Autentisering av begärandehuvud

Den autentiseringsmetod som rekommenderas är att skicka ett begärandehuvud med namnet SessionID som innehåller sessionstoken. Fördelen med detta är att det är säkert mot CSRF-attacker (Cross-site Request Forgery) och att det inte stör URI:n för cachelagring.

Följande är ett exempel på en begäranderubrik:

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