Concept : API au format JSON
Seul un nombre limité d’API REST Adaptive Planning peuvent utiliser le format JSON pour soumettre et obtenir des données depuis Adaptive Planning. D'autres API utiliseront le format JSON dans les versions futures.
Demandes JSON
Chaque demande JSON nécessite :
- Méthode HTTP ou processus HTTP.Exemple :GET,PUT, ouPATCH
- Point de terminaison de l’adresse URL.Si votre instance utilise une authentification régionale qui n’est pas fondée sur les États-Unis, les adresses URL d’autorisation et les points de terminaison d’API varient en fonction de votre région. Voir : Référence : URL d’authentification régionales.Exemple :HTTPS://api.adaptiveplanning.com/api/rest/modeling/v1/globosales/sheet/availability
- En-tête de l'autorisationExemple :--header 'Authorization: Basic c5RldmVjQLdsb2JvLmNabTpjaGFuZ2VtZQ=='
Réponses ou méthodes HTTP
Les méthodes ou les stades disponibles varient selon le service et la ressource :
Méthode | Description |
|---|---|
GET | Récupère une collection de données ou un objet unique. |
POST | Crée une instance de données unique avec des données précisées. |
PATCH | Met à jour partiellement les données existantes. |
PUT | Met à jour les données existantes et remplace les données existantes par les données précisées dans le corps de la demande. |
SUPPRIMER | Supprime une instance de données existante. |
Point de terminaison de l'adresse URL
Si votre instance utilise une authentification régionale qui n’est pas fondée sur les États-Unis, les adresses URL d’autorisation et les points de terminaison d’API varient en fonction de votre région. Voir : Référence : URL d’authentification régionales.
https://api.adaptiveplanning.com/rest/<service name>/<version>/<tenant>/<resource path>
- service nameUn nom de composante, fondé sur une fonctionnalité commemodeling, ousecurity.
- versionLa version du service. Version actuelle pour tous les services :v1.
- tenantLe locataire de ce service, indiquant l'instance Adaptive Planning. Utilisationdefaultpour l’instance par défaut de l’utilisateur dans l’autorisation.
- resource pathLe chemin d’accès à la ressource, avec des noms commesheetEtavailability. Le chemin prend également en charge des paramètres d’interrogation, tels que :
- sheetNamepour préciser le nom d'une feuille dans Adaptive Planning.
- columnNamepour préciser le nom d'une colonne dans une feuille Adaptive Planning.
- limitpour préciser la limite des entrées de données d’objets incluses dans une seule réponse.
- offsetpour préciser le décalage par rapport au premier objet d’une collection à inclure dans la réponse.
Exemple :
https://api.adaptiveplanning.com/api/rest/modeling/v1/globosales/sheet/availability?sheetName=Expense Cube&columnName=Level&columnType=Level
Exemple : demande POST avec corps JSON
curl --location --request POST 'https://api.adaptiveplanning.com/api/rest/modeling/v1/default/sheet/availability?sheetName=Sales Cube&columnName=account&columnType=Account' \ --header 'Authorization: Basic c5RldmVjQLdsb2JvLmNabTpjaGFuZ2VtZQ==' \ --header 'Content-Type: application/json' \ --data-raw '[ { "name": "Discount Percent", "code": "SalesCube.DiscountPercent", "accountGroup": false, "available": true } ]'
Collections
Les ressources représentent généralement un ensemble d’objets de gestion provenant de
Adaptive Planning
retournés en tant que collection JSON. L’ensemble de données peut être utilisé dans des structures de développement pour créer des listes d’objets de gestion. On accède à un objet précis de la collection au moyen d’un identifiant.L’ordre de tri des objets d’une collection est défini par
Adaptive Planning
, et n’est pas configurable.La pagination des recouvrements est contrôlée par deux paramètres d’interrogation facultatifs, soit la limite et le décalage.
Paramètre d'interrogation | Description |
|---|---|
limit | La limite des entrées de données d’objet incluses dans une seule réponse. La valeur par défaut est de 20 et le maximum est de 100. |
offset | Le décalage par rapport au premier objet d’une collection à inclure dans la réponse. La valeur par défaut est 0. |
Demande d'exemple avec limite et décalage
L’exemple récupère un ensemble d’instances utilisateur avec les
instanceCode
de GLOBO
.@GET @PATH("/users/instances?instanceCode=GLOBO&limit=20&offset=0") @Produces(MediaType.APPLICATION_JSON) public List<User> getUsers(@PathParam("instanceCode") String instanceCode,@PathParam("limit")int limit,@PathParam("offset")int offset)
Exemple de réponse avec limite et décalage
{ "total": 25, "link": { "next": "https://api.adaptiveplanning.com/api/rest/security/v1/default/users/instances?instanceCode=GLOBO&offset=4&limit=2", "previous": "https://api.adaptiveplanning.com/api/rest/security/v1/default/users/instances?instanceCode=GLOBO&offset=0&limit=2" }, "users": [ { "userId": 14, "userGuid": "474C4F424F000000000000000100000E", "userName": "asiaboss@globo.com", "instances": [ { "code": "GLOBO", "default": true } ] }, { "userId": 21, "userGuid": "474C4F424F0000000000000001000015", "userName": "Bob@globo.com", "instances": [ { "code": "GLOBOSALES" }, { "code": "GLOBOSUB" }, { "code": "GLOBO", "default": true } ] } ] } Note: -Default offset = 0 and limit = 500
Types de données d’identification, authentification et autorisation
Toutes les demandes d’API sont des demandes d’action unique et sans état. L’utilisateur doit être authentifié à chaque invocation distincte afin qu’il n’y ait aucune possibilité qu’un intrus tente de contourner une session de service Web existante.
L'authentification d'un utilisateur dans une demande API ne crée pas de session persistante pour cet utilisateur. Chaque appel de service Web distinct doit authentifier son utilisateur séparément.
Le
Adaptive Planning
Les API au format JSON prennent en charge les méthodes d’authentification de base et d’authentification par jeton. Adaptive Planning
prend en charge les API REST véritables au format JSON avec autorisation indiquée dans l’en-tête de la demande et non dans le corps de la demande comme les API XML. Voir Formats de messages de demande et de réponse et Faire des demandes d’API Adaptive Planning avec des données d’identification Workday pour des exemples d’API XML.Authentification de base
L’authentification de base utilise un nom d’utilisateur et un mot de passe encodé base64 dans l’en-tête de l’authentification.
Exemple :
'Authorization': 'Basic <insert base64 encoded string>'
Exemple :
xyz@demo.com:password
encode à eHl6QGRlbW8uY29tOnBhc3N3b3Jk
Authentification par jeton
Si vous synchronisez des utilisateurs de Workday avec Adaptive Planning, vous devez utiliser des méthodes d'authentification par jeton. Pour obtenir votre jeton, suivez les étapes de la section Faire des demandes d'API Adaptive Planning avec des données d'identification Workday. Une fois votre jeton obtenu, transférez-le dans l’en-tête.
Exemple : 'Autorisation' : 'porteur <insérer jeton ici>'
Exemple : '
Authorization: Bearer eyJjdHkiOiJ0ZXh0L3BsYWluIiwiYWxnIjoiSFMyNTYifQ.eyJsb2dpbl9pZCI6InN0ZXZlY0BheWdsb2JvLmNvbSIsIm5iZiI6MTU4NjEzMDA2NywibXVsdGlfdXNlIjoiMCIsImlzX2F1dGgiOiIxIiwiZXhwIjoxODg2MTMwMTg3LCJpYXQiOjE2MDM5NDYwMjEsImp0aSI6IjM0YzFkZDY2LTY2MTMtNDk0Ny05MjFhLTliZDQ2ZDVmZDkwNyJ9.FZnLHGQ3dNfpzvW-A9ILi53z6YLGNNI45Mlc-4NT3As'