Cas pratiques FastAPI

Contexte : Une route doit retourner un statut spécifique après création d'une ressource. Le Problème : L'endpoint renvoie toujours un code 200 par défaut. Contraintes : Utiliser le paramètre status_code du décorateur. Livrable attendu : Modifier un endpoint POST pour retourner un code 201 Created après succès.

Contexte : L'application FastAPI doit être exécutée en environnement local. Le Problème : Le serveur n'est pas correctement lancé avec autoreload. Contraintes : Utiliser uvicorn avec option --reload. Livrable attendu : Configurer correctement le lancement de l'application afin de permettre le rechargement automatique en développement.

Contexte : Un endpoint FastAPI renvoie un type de donnée non sérialisable. Le Problème : Une erreur de sérialisation est déclenchée. Code actuel : @app.get('/test') def test(): return set([1, 2, 3]) Contraintes : Retourner un type JSON compatible. Livrable attendu : Corriger l'endpoint afin qu'il retourne une structure sérialisable (liste ou dict) compatible JSON.

Contexte : Vous démarrez un microservice FastAPI pour un projet interne et devez valider rapidement son bon fonctionnement. Le Problème : Aucun endpoint n'est encore exposé pour vérifier que l'application répond correctement. Contraintes : Utiliser FastAPI natif sans dépendances externes supplémentaires. L'application doit être exécutable avec uvicorn. Livrable attendu : Implémenter un endpoint GET /health retournant un JSON { "status": "ok" } avec code HTTP 200 et vérifier son accessibilité via le navigateur ou curl.

Contexte : Une route doit récupérer une ressource via son identifiant. Le Problème : Le paramètre d'URL n'est pas correctement exploité. Contraintes : Utiliser les path parameters FastAPI avec typage explicite. Livrable attendu : Implémenter une route GET /items/{item_id} retournant l'identifiant reçu avec validation automatique du type.

Contexte : Une ressource demandée peut ne pas exister. Le Problème : L'application ne retourne pas d'erreur claire lorsque l'objet est introuvable. Contraintes : Utiliser HTTPException. Livrable attendu : Implémenter une gestion d'erreur retournant un code 404 et un message explicite lorsque la ressource n'est pas trouvée.

Contexte : Une API doit recevoir des données utilisateur structurées. Le Problème : Les données envoyées ne sont pas validées automatiquement. Contraintes : Utiliser un modèle Pydantic pour définir la structure attendue. Livrable attendu : Créer un endpoint POST /users acceptant un modèle Pydantic et retournant les données validées en réponse JSON.

Contexte : Une route retourne des données mais le format doit être contrôlé. Le Problème : Les champs sensibles ne doivent pas apparaître dans la réponse. Contraintes : Utiliser response_model dans le décorateur. Livrable attendu : Implémenter un modèle de sortie filtrant certains champs et l'utiliser comme response_model.

Contexte : Une route doit valider qu'un identifiant soit strictement positif. Le Problème : Aucun contrôle n'empêche les valeurs négatives. Contraintes : Utiliser des types Pydantic avec validation (conint). Livrable attendu : Implémenter un endpoint validant automatiquement qu'un paramètre numérique soit supérieur à zéro.

Contexte : Une route doit accepter un paramètre optionnel en query string. Le Problème : Le paramètre n'est pas typé ni validé. Contraintes : Utiliser typing.Optional pour le paramètre. Livrable attendu : Implémenter une route GET /search acceptant un paramètre optionnel q et retournant sa valeur en JSON.

Contexte : L'application doit être déployée en production. Le Problème : Certaines configurations sensibles sont codées en dur. Contraintes : Utiliser variables d'environnement et configuration centralisée. Livrable attendu : Mettre en place une gestion de configuration sécurisée adaptée à un environnement production.

Contexte : L'application doit persister ses données dans une base relationnelle. Le Problème : La gestion actuelle de la session base de données est mal structurée. Contraintes : Configurer SQLAlchemy avec gestion propre des sessions via dépendances. Livrable attendu : Implémenter une configuration propre de la base de données incluant session lifecycle et injection via Depends.

Contexte : L'équipe souhaite tracer toutes les requêtes et leur durée d'exécution. Le Problème : Aucun mécanisme centralisé de logging n'est en place. Contraintes : Utiliser BaseHTTPMiddleware. Livrable attendu : Implémenter un middleware mesurant le temps d'exécution des requêtes et loggant méthode, route et durée.

Contexte : L'application doit accepter des fichiers envoyés par les utilisateurs. Le Problème : Aucun contrôle sur type ou taille n'est implémenté. Contraintes : Utiliser UploadFile et valider type MIME et taille maximale. Livrable attendu : Mettre en place un endpoint sécurisé d'upload avec validation stricte et gestion d'erreur appropriée.

Contexte : Une API retourne de grandes listes d'objets. Le Problème : Toutes les données sont envoyées en une seule réponse. Contraintes : Implémenter une pagination via query parameters (limit, offset). Livrable attendu : Ajouter un système de pagination permettant de limiter le nombre d'éléments retournés et d'améliorer la performance.

Contexte : Une API multi-utilisateurs doit restreindre l'accès à certains endpoints selon le rôle. Le Problème : Aucun contrôle d'autorisation n'est implémenté. Contraintes : Créer une dépendance vérifiant le rôle utilisateur. Livrable attendu : Mettre en place un système RBAC simple basé sur JWT et dépendances FastAPI pour sécuriser dynamiquement les routes.

Contexte : Une API doit protéger certains endpoints accessibles uniquement aux utilisateurs authentifiés. Le Problème : Aucun système d'authentification par token n'est en place. Contraintes : Utiliser python-jose ou équivalent pour JWT et dépendances FastAPI pour vérification. Livrable attendu : Mettre en place une génération de JWT et une dépendance sécurisant les routes protégées via vérification du token.

Contexte : Les erreurs sont retournées avec des formats incohérents. Le Problème : Aucun gestionnaire global d'exception n'est configuré. Contraintes : Utiliser @app.exception_handler. Livrable attendu : Mettre en place un gestionnaire global garantissant un format JSON uniforme pour toutes les erreurs applicatives.

Contexte : Un endpoint effectue un calcul lourd ou une requête lente. Le Problème : Chaque requête relance le traitement complet. Contraintes : Implémenter un cache mémoire simple avec TTL. Livrable attendu : Ajouter un mécanisme de cache réduisant les traitements redondants et améliorant les performances.

Contexte : Votre application FastAPI commence à grandir et tous les endpoints sont définis dans un seul fichier main.py. Le Problème : Le fichier devient difficile à maintenir et les responsabilités ne sont pas clairement séparées. Contraintes : Utiliser APIRouter pour organiser les routes par domaine (users, auth, items). Conserver une structure propre et évolutive. Livrable attendu : Refactoriser l'application en architecture modulaire avec routers séparés et inclusion propre dans l'application principale.

Contexte : Une application monolithique doit évoluer vers une architecture distribuée. Le Problème : Les services sont fortement couplés et déployés ensemble. Contraintes : Utiliser un message broker comme RabbitMQ ou Kafka avec communication événementielle. Livrable attendu : Concevoir une architecture microservices FastAPI avec communication asynchrone fiable et découplage complet des domaines métier.

Contexte : Une plateforme SaaS doit gérer plusieurs organisations avec rôles hiérarchiques. Le Problème : Les règles d'autorisation actuelles sont statiques et insuffisantes. Contraintes : Implémenter un système RBAC/ABAC dynamique basé sur dépendances FastAPI. Livrable attendu : Concevoir un moteur d'autorisation flexible capable de gérer multi-tenant, rôles complexes et permissions dynamiques.

Contexte : Votre API FastAPI a grandi rapidement et mélange endpoints, logique métier et accès base de données dans les mêmes modules. Le Problème : Le couplage fort rend les tests difficiles et limite l'évolutivité de l'application. Contraintes : Implémenter une architecture hexagonale séparant domaine, cas d’usage et infrastructure. Le domaine ne doit dépendre ni de FastAPI ni de SQLAlchemy. Livrable attendu : Proposer une structure complète incluant entités métier, services applicatifs, interfaces de repository et adaptateurs techniques garantissant testabilité et maintenabilité.

Contexte : Une API SaaS doit gérer des sessions longue durée de manière sécurisée. Le Problème : Les access tokens expirent rapidement et aucun mécanisme robuste de rotation de refresh token n'est en place. Contraintes : Implémenter JWT avec access token court, refresh token stocké en base et rotation automatique avec invalidation. Livrable attendu : Concevoir un système complet garantissant génération sécurisée, rotation contrôlée et révocation des tokens compromis.

Contexte : Plusieurs services doivent effectuer des opérations coordonnées sur différentes bases de données. Le Problème : En cas d'échec intermédiaire, l'état global devient incohérent. Contraintes : Implémenter un pattern Saga avec orchestration ou choreography. Livrable attendu : Concevoir une stratégie garantissant cohérence globale via transactions distribuées et mécanismes de compensation.

Contexte : Une application temps réel doit supporter plusieurs milliers de connexions simultanées. Le Problème : En environnement multi-instance, les messages ne sont pas synchronisés. Contraintes : Utiliser Redis ou autre mécanisme de synchronisation inter-processus. Livrable attendu : Concevoir une architecture WebSocket scalable permettant synchronisation fiable entre instances FastAPI.

Contexte : L'API publique doit répondre à des exigences élevées de sécurité. Le Problème : Certaines protections contre injection, brute force ou exposition d'erreurs sont insuffisantes. Contraintes : Mettre en place validation stricte, rate limiting et sécurisation des headers. Livrable attendu : Concevoir une stratégie complète de sécurisation alignée avec les recommandations OWASP.

Contexte : L'application est déployée sur plusieurs instances en production. Le Problème : Les erreurs et lenteurs sont difficiles à diagnostiquer. Contraintes : Intégrer OpenTelemetry ou équivalent pour tracing distribué et métriques. Livrable attendu : Mettre en place une architecture d'observabilité complète incluant logs structurés, métriques et traçage inter-services.

Contexte : Certains endpoints critiques subissent une forte charge. Le Problème : Les requêtes base de données deviennent un goulot d'étranglement. Contraintes : Intégrer Redis comme backend de cache avec stratégie d'invalidation fine. Livrable attendu : Mettre en place un système de cache distribué performant garantissant cohérence des données et amélioration significative de la latence.

Contexte : L'application doit être déployée dans un environnement cloud avec autoscaling. Le Problème : L'architecture actuelle dépend d'états locaux et n'est pas optimisée pour la scalabilité horizontale. Contraintes : Rendre l'application stateless, externaliser sessions et cache, préparer conteneurisation. Livrable attendu : Proposer une architecture cloud-native compatible Docker et orchestrateurs, garantissant scalabilité et haute disponibilité.