Comptes et accès
Distinguer l’identité de l’utilisateur de ses droits. Définir la propriété des données, les rôles, les sessions et les contrôles dans l’API ; masquer un bouton côté client ne suffit pas à gérer l’accès.
Développer des backends et API avec .NET.
Une application mobile et une interface de gestion partagent souvent comptes, données et règles métier. FlowApps LAB développe des backends .NET et ASP.NET Core reliant ces clients aux données relationnelles et aux autres systèmes. Les opérations à réaliser guident d’abord le travail, puis la définition des droits, des entrées et des résultats de l’API.
Définir les responsabilités du serveur
Règles métier et validation
Placer les règles communes sur le serveur pour éviter des résultats contradictoires entre clients. Préciser les champs requis, les transitions autorisées, les requêtes répétées et la façon d’expliquer un refus au client.
Données relationnelles et intégrations
Modéliser les données et leurs relations avant les endpoints. Le travail sur PostgreSQL ou SQL Server peut couvrir schémas, requêtes et migrations. Pour les systèmes externes, préciser les responsabilités, les accès, les erreurs et les conditions de reprise.
Exemple de flux : application → API → données
Cette demande de travail fictive illustre les responsabilités ; ce n’est ni un cas client ni une description de VitaFlow.
Application ou interface de gestion
L’utilisateur connecté envoie l’identifiant du dossier et l’action souhaitée. Le client affiche les retours de validation sans décider des droits des autres utilisateurs.
Contrôle dans l’API
L’API vérifie l’identité, l’accès au dossier et la transition autorisée. Elle refuse les données invalides ou exécute l’opération, puis renvoie un résultat documenté compris par les deux clients.
Données et réponse
La couche de données enregistre le changement dans les relations et transactions prévues. L’API renvoie l’état enregistré ; un échec d’intégration exige un chemin de reprise défini plutôt qu’un succès trompeur.
Définir le contrat et la mise en production
Documenter les requêtes, les réponses, les erreurs, la pagination et la compatibilité. Tester les opérations acceptées et refusées, y compris les échecs d’intégration. Avant la mise en production, convenir de la configuration, des identifiants confidentiels, des migrations, des journaux, des sauvegardes et du retour à la version précédente. L’accès à l’hébergement et les responsabilités influencent le travail ; la préparation de la mise en production ne se mesure pas au seul nombre de points d’accès API.
Checklist pour cadrer l’API
Des opérations concrètes et les contraintes existantes permettent de distinguer une simple intégration d’un backend responsable d’un processus complet.
- Quels clients utiliseront l’API et quels rôles pourront consulter ou modifier chaque donnée ?
- Quelles données existent, où sont-elles stockées et faut-il les migrer ou les nettoyer ?
- Quels systèmes externes interviennent et disposez-vous de documentation, de comptes de test et d’accès ?
- Que doit-il se passer en cas de doublon, de refus d’accès, de mise à jour partielle ou de dépendance indisponible ?
- Qui est responsable de l’hébergement, de la validation et de l’exploitation, et quels résultats vérifiables définissent la réception ?