Bases d’API

Dernière mise à jour : 5 décembre 2024
  • Rubriques :

Créé pour :

  • Développeur

L’objectif de l’API Adobe Workfront est de simplifier la création d’intégrations avec Workfront en introduisant une architecture REST qui fonctionne sur HTTP. Ce document suppose que vous connaissez les réponses REST et JSON et décrit l’approche adoptée par l’API Workfront.

Une bonne connaissance du schéma Workfront vous aidera à comprendre les relations entre les bases de données qui peuvent être utilisées pour extraire des données de Workfront à des fins d’intégration.

Politiques et directives

Pour garantir des performances système Workfront à la demande cohérentes, l’API Workfront limite les threads API simultanés. Cette barrière de sécurité empêche les problèmes système causés par les appels d’API abusifs. L’environnement Sandbox dispose de la même limite de thread d’API simultanée, ce qui permet aux clients et aux partenaires de tester précisément les appels d’API avant de publier du code en production.

Pour les environnements de production, de prévisualisation et de test, les demandes des utilisateurs et utilisatrices finaux ont une longueur maximale d’URI de 8 892 octets parce qu’elles sont acheminées par le CDN de Workfront (Akamai). Cette limite ne s’applique qu’aux URI acheminés par le CDN.

Avertissement

Toute utilisation de l’API doit être testée dans l’environnement bêta de Workfront avant d’être exécutée dans l’environnement de production. Si un client ou une cliente utilise l’API pour un processus que Workfront considère raisonnablement comme une charge pour le logiciel à la demande (c’est-à-dire que le processus a un effet négatif important sur la performance du logiciel pour d’autres clientes et clients), Workfront se réserve le droit de demander au client ou à la cliente d’interrompre ce processus. Si le client ou la cliente ne se conforme pas et que le problème persiste, Workfront se réserve le droit de mettre fin au processus.

URL de l’API Workfront

Pour plus d’informations sur l’URL que vous utiliserez pour appeler l’API Workfront, voir Format de domaine pour les appels API Adobe Workfront.

Concepts de base de REST

Cette section fournit une introduction de haut niveau sur la façon d’interagir avec l’API REST de Workfront pour les principes REST suivants :

URI d’objet

Chaque objet du système se voit attribuer un URI unique composé du type d’objet et de l’ID. Les exemples suivants montrent des URI décrivant trois objets uniques :

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

Le type d’objet n’est pas sensible à la casse et peut être soit le code ObjCode abrégé (tel que proj), soit le nom alternatif de l’objet (projet).

Pour obtenir la liste des objets, des ObjCodes et des champs d’objet valides, voir  Explorateur API.

REMARQUE
Dans le contexte de l’API Workfront, un formulaire personnalisé est un objet Category et un champ personnalisé est un objet Parameter.

Opérations

Les objets sont manipulés en envoyant une requête HTTP à leur URI unique. L’opération à effectuer est spécifiée par la méthode HTTP.

Les méthodes HTTP standard correspondent aux opérations suivantes :

  • GET - Permet de récupérer un objet par son ID, de rechercher tous les objets par une requête, d’exécuter des rapports ou des requêtes nommées.
  • POST - Insère un nouvel objet.
  • PUT - Modifie un objet existant.
  • DELETE - Supprime un objet.

Afin de contourner les déficiences du client ou les limites de longueur du protocole, le paramètre de méthode peut être utilisé pour modifier le comportement du protocole HTTP. Par exemple, une opération GET peut être mise en œuvre en publiant l’URI suivant :

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