- Démarrage
- Lisez-moi
- À propos d'OData et des références
- URL d'Orchestrator
- Références d'API
- Rate limits and large data fields usage optimization
- Ressources logiques et métadonnées
- Opérations disponibles
- Fichiers énumérés (Enumerated Files)
- Utilisation de l'API de cloud
- Création des requêtes d'API
- Applications externes (OAuth)
- Autorisations par point de terminaison
- Codes de réponse
- Définition Swagger
- Exemples d'utilisation de l'API Orchestrator
- Demandes d'alertes
- Requêtes relatives aux actifs
- Requêtes de calendriers
- Requêtes relatives aux environnements
- Requêtes de dossiers
- Requêtes de tâches génériques
- Requêtes relatives aux tâches
- Requêtes relatives aux bibliothèques
- Requêtes relatives aux licences
- Requêtes relatives aux paquets (Packages Requests)
- Requêtes relatives aux autorisations
- Demandes d'espaces de travail personnels
- Requêtes relatives aux processus
- Traiter les requêtes liées à la stratégie de conservation des données
- Demandes d'éléments de la file d'attente
- Requêtes en matière de stratégie de rétention des files d’attente
- Requêtes relatives aux Robots
- Requêtes relatives aux rôles (Roles Requests)
- Requêtes relatives aux planifications
- Requêtes relatives aux paramètres
- Requêtes de compartiments de stockage
- Requêtes de tâches
- Demandes de catalogues de tâches
- Demandes de formulaires de tâches
- Requêtes relatives aux locataires
- Requêtes relatives aux transactions
- Requêtes relatives aux utilisateurs
- Requêtes relatives aux Webhooks
Lisez-moi
Nous prévoyons de mettre à niveau la version Swagger d'Orchestrator vers Swagger 3.0 (actuellement, les API d'Orchestrator sont définies à l'aide de Swagger 2.0).
Ne vous inquiétez pas de la rétrocompatibilité avec vos clients API existants : nous veillerons à ce que l'API reste compatible.
Nous vous recommandons d’utiliser vos clients précédents, car les modifications JSON ne les modifient pas, grâce à la rétrocompatibilité de notre structure de requête.
Si vous prévoyez d'intégrer nos API à votre client, vous devez être conscient des mises à jour et des modifications possibles qui peuvent survenir à la définition Swagger, aux schémas JSON ou aux points de terminaison d'API.
La liste ci-dessous fournit des informations et des recommandations concernant les modifications avec Swagger. Si vous avez d’autres questions, contactez notre équipe d’assistance.
- La description de l'API JSON représentée dans le document Swagger JSON peut changer à tout moment. Cependant, il décrira la même API sous-jacente, pour assurer la rétrocompatibilité.
- L'interface Swagger et le JSON correspondant sont générés en fonction des points de terminaison actuels, et nous publions toujours la dernière version. Pour garantir la rétrocompatibilité, nous prenons en charge la même structure de requête.
- Comme alternative aux clients API générés au runtime, utilisez des clients API à temps fixe ou à temps de compilation. Cela réduit la dépendance et empêche les mises à jour d'automatisation majeures en cas de modification de l'API ou de la définition Swagger.
- Les éléments marqués comme obsolètes sont disponibles pendant une durée limitée, après quoi les éléments sont supprimés de la définition Swagger et de l'API JSON.
- Chaque fois que certaines API changent en interne, une nouvelle version de l'API Swagger est publiée. Le numéro de version de l'API n'influence pas l'utilisation de l'API cliente. Nous vous déconseillons de vous fier à la gestion des versions de l’API.
Les exemples fournis dans le document de référence Orchestrator existant décrivent des scénarios et des points de terminaison complexes.
Vous pouvez voir toutes les API disponibles dans le Swagger JSON, qui contient les dernières mises à jour.
Découvrez comment accéder à Orchestrator Swagger, en fonction du mode de déploiement d'Orchestrator.
