Scolaire
TaskFlow — API REST de gestion de projets avec ASP.NET Core
API REST académique de gestion de projets et de tâches, réalisée avec ASP.NET Core et un modèle relationnel SQL Server géré par Entity Framework Core.
Ma contribution
J'ai réalisé l'ensemble de l'implémentation technique actuelle de l'API : architecture ASP.NET Core, services, modèle EF Core, authentification, validation, gestion des erreurs et documentation Swagger.
Points clés
- Modèle relationnel utilisateurs, projets et tâches, versionné par une migration EF Core
- Logique métier dans des services injectés, séparée des contrôleurs HTTP
- Gestion centralisée des erreurs, traduites en codes HTTP adaptés
Objectif
Développer l’API d’un outil de gestion de projets : des utilisateurs, des projets qui leur appartiennent et des tâches rattachées à ces projets. Le résultat est une API REST académique, sans prétention à être une plateforme complète de gestion de projet.
Architecture
L’API repose sur ASP.NET Core et .NET 9. L’application sépare les contrôleurs HTTP de la logique métier portée par des services injectés, déclarés derrière des interfaces. Ces services utilisent directement Entity Framework Core pour l’accès aux données. Les échanges passent par des objets de transfert (DTO) distincts des entités, et un middleware traite toutes les exceptions de façon centralisée ; les journaux sont écrits sur la console.
Fonctionnalités
- Comptes : inscription et connexion, avec un jeton JWT valable deux heures.
- Projets : création, lecture, modification et suppression ; chaque projet est associé à l’utilisateur connecté qui le crée.
- Tâches : création, lecture, modification et suppression, avec un statut, une échéance et des commentaires.
- Démonstration : en plus de l’interface Swagger, une petite page HTML permet d’essayer l’API.
Modèle de données
Le modèle est relationnel et stocké dans SQL Server : un utilisateur possède des projets, et chaque projet contient des tâches. Les clés étrangères relient ces entités, avec suppression en cascade, et un index unique garantit qu’une adresse e-mail n’est utilisée qu’une fois. Le schéma est décrit par une migration Entity Framework Core versionnée, plutôt que créé dynamiquement au fil des écritures. Les requêtes s’écrivent en LINQ et chargent les entités liées lorsque c’est nécessaire.
Validation et erreurs
Les DTO portent des règles de validation déclaratives — champs obligatoires, format d’e-mail, longueur minimale — appliquées automatiquement par ASP.NET Core avant d’atteindre le code métier. Les erreurs sont centralisées : un middleware intercepte les exceptions et les traduit en codes HTTP adaptés (conflit, ressource introuvable, accès refusé, requête invalide), avec un message détaillé en développement et neutre sinon.
Authentification et documentation
Les jetons JWT sont signés et vérifiés par le framework — émetteur, audience, expiration et signature — et les routes des projets et des tâches sont réservées aux utilisateurs authentifiés. La documentation OpenAPI est générée et consultable dans Swagger, configuré pour envoyer le jeton et afficher les énumérations de façon lisible.
Limites
Le projet est resté une API académique : les rôles prévus dans le modèle et certaines règles de cloisonnement des ressources n’ont pas été finalisés, et aucune suite de tests automatisés n’a été ajoutée.