Formation en ligne par Autodesk® Developer qui introduit l’utilisation de l’API ACC Issues avec NodeJS .
Le formateur, John Wu, explique l’objectif de la session, qui est de construire une application web pour gérer les problèmes ACC, en commençant par la configuration de l’application côté serveur et en passant par la création d’une interface utilisateur côté client. Il décrit l’architecture de l’application web , impliquant la communication entre le client, le serveur et les services API via le SDK ACC , et fournit les informations d’identification requises pour la configuration, telles qu’un compte APS et un compte ACC test . La fin du texte détaille les premières étapes pratiques pour initialiser le projet NodeJS et installer les dépendances nécessaires.
Téléchargez la présentation détaillée en PDF:
Bâtir_une_Application_de_Gestion_des_Problèmes.pdf (11,4 Mo)
Architecture d’une Application Web avec l’API Autodesk® Construction Cloud
Introduction
Bienvenue ! Ce document a pour objectif de vous expliquer de manière simple et claire l’architecture d’une application web conçue pour interagir avec les API d’Autodesk®. Pour bien comprendre, imaginez que nous construisons une application avec une équipe de trois membres, où chacun a un rôle bien précis et indispensable. Cette architecture à trois niveaux n’est pas une simple recette ; c’est un modèle standard et robuste qui permet de créer des applications web évolutives et faciles à maintenir. Ensemble, ces composants permettent à un utilisateur de consulter des données de projet stockées dans le cloud d’Autodesk®.
1. Vue d’Ensemble : Les Trois Composants Principaux
Toute l’application repose sur l’interaction entre trois composants fondamentaux : le Client (ce que l’utilisateur voit), le Serveur (le moteur de l’application) et le Service API d’Autodesk® Cloud (la source des données).
1.1. Tableau Récapitulatif des Rôles
Le tableau ci-dessous résume le rôle de chaque composant pour vous donner une vue d’ensemble rapide.
| Composant | Rôle Principal | Analogie Simple |
|---|---|---|
| Client (Frontend) | Affiche l’interface utilisateur (UI), comme la vue en arborescence et le tableau de données, avec laquelle l’utilisateur interagit. | La vitrine du magasin |
| Serveur (Backend) | Traite les demandes de l’utilisateur, contient la logique métier et communique avec les services Autodesk®. | L’arrière-boutique et le gérant |
| Service API d’Autodesk® Cloud | Sert de source de données sécurisée et centralisée pour toutes les informations des projets Autodesk®. | L’entrepôt central de données |
1.2. Le Rôle du Client (Frontend)
Le Client est la partie visible de l’application, celle que vous voyez dans votre navigateur. Son travail consiste à présenter les informations de manière claire et à capturer les actions de l’utilisateur. Dans notre exemple, il se compose principalement de deux éléments visuels :
- Une vue en arborescence qui permet de naviguer à travers la hiérarchie des comptes et des projets Autodesk®.
- Un tableau principal qui liste les détails des « problèmes » (issues) associés à un projet sélectionné.
Le Client ne contient pas les données ; il se contente de les afficher et d’envoyer les requêtes de l’utilisateur au Serveur.
1.3. Le Rôle du Serveur (Backend)
Le Serveur est le cerveau de l’application. Il fonctionne en arrière-plan et héberge des « points de terminaison » (endpoints), qui sont des adresses spécifiques conçues pour répondre à des requêtes précises (par exemple, un endpoint pour récupérer les problèmes, un autre pour créer un problème, ou même pour lister les utilisateurs du projet). Le Serveur agit comme un intermédiaire crucial : il reçoit les demandes du Client, puis se charge de communiquer avec le cloud d’Autodesk® pour récupérer ou envoyer les données nécessaires.
1.4. Le Rôle du Service API d’Autodesk® Cloud
Le Service API d’Autodesk® Cloud est la source où toutes les données des projets (problèmes, documents, modèles, etc.) sont stockées et gérées de manière sécurisée. C’est la source de vérité ultime. Plus qu’une simple base de données, l’API fonctionne comme un contrat formel : elle définit un ensemble de règles et de capacités précises sur ce qu’une application peut demander et recevoir. La documentation de référence de l’API (API Reference) est le guide du développeur pour comprendre ce contrat. Le Serveur de notre application ne stocke pas ces données ; il les demande au Service API chaque fois que l’utilisateur en a besoin, garantissant que les informations affichées sont toujours à jour.
Maintenant que nous avons rencontré les trois acteurs principaux, voyons comment ils communiquent entre eux pour afficher les données à l’utilisateur.
2. Le Flux de Données : Comment les Composants Communiquent
La communication entre ces trois parties suit une séquence logique et bien définie. Voici le parcours d’une demande de données, depuis le clic de l’utilisateur jusqu’à l’affichage des informations à l’écran.
2.1. Étape 1 : L’utilisateur fait une demande
Tout commence avec l’utilisateur qui interagit avec le Client (l’interface web). Par exemple, il clique sur un nom de projet dans la vue en arborescence pour en afficher les problèmes associés.
2.2. Étape 2 : Le Client envoie une requête au Serveur
L’application Cliente traduit ce clic en une requête formelle. Cette requête est envoyée via le réseau à un endpoint spécifique sur le Serveur. Par exemple, elle pourrait demander : « Donne-moi tous les problèmes pour le projet X ».
2.3. Étape 3 : Le Serveur utilise le SDK pour interroger Autodesk®
C’est une étape essentielle. Le Serveur ne communique pas directement avec l’API Autodesk®. Il utilise plutôt le SDK Autodesk® (Software Development Kit). Le SDK est une boîte à outils spécialisée qui rend la communication avec l’API « pratique et facile ». Concrètement, cela signifie que le SDK gère pour nous des tâches complexes et répétitives que nous devrions sinon coder manuellement, telles que :
- Gérer les jetons d’authentification et leur renouvellement.
- Formater correctement les requêtes HTTP pour chaque endpoint spécifique.
- Analyser les réponses JSON de l’API pour les transformer en objets utilisables.
- Simplifier la gestion des erreurs.
En bref, le SDK permet au développeur de se concentrer sur la logique de l’application plutôt que sur les détails techniques de la communication réseau.
2.4. Étape 4 : Le SDK communique avec le Service API d’Autodesk® Cloud
Le SDK prend la demande du Serveur et la transmet, via Internet, au Service API d’Autodesk® Cloud. C’est à ce moment que notre application demande officiellement les données aux systèmes d’Autodesk®.
2.5. Étape 5 : Le retour des données
Une fois la demande traitée, les informations voyagent en sens inverse pour revenir à l’utilisateur :
- Le Service API d’Autodesk® envoie les données demandées (par exemple, la liste des problèmes) en réponse au SDK.
- Le SDK reçoit cette réponse et la transmet de manière structurée à l’endpoint du Serveur.
- L’endpoint du Serveur envoie à son tour les données formatées au Client.
- Le Client reçoit enfin les données et les utilise pour générer (ou ‹ rendre ›) l’affichage mis à jour, par exemple en remplissant le tableau avec la liste des problèmes et leurs détails.
Ce flux structuré garantit que chaque composant ne fait que son propre travail, rendant l’application à la fois organisée et efficace.
3. Conclusion : Synthèse de l’Architecture
Vous comprenez maintenant l’architecture à trois niveaux qui est au cœur de nombreuses applications web modernes. Cette séparation des rôles est une pratique fondamentale en développement :
- Le Client s’occupe de la présentation.
- Le Serveur gère la logique.
- Le Service API fournit les données.
Ce modèle fondamental de séparation entre présentation, logique et données est la clé pour construire des applications puissantes et flexibles. Vous avez maintenant les bases nécessaires pour aborder n’importe quelle intégration d’API ou pour comprendre d’autres systèmes complexes.