TP3.2 — Application CRUD Complète (Mode Autonome)
Ce TP reprend exactement le même énoncé que le TP3.1, mais sans aucun code fourni. Vous devez tout réaliser par vous-même. Si vous êtes bloqué, consultez le TP3.1 comme référence.
Durée estimée : 2h à 3h
Prérequis : Avoir compris les concepts du Module 3 (architecture en couches, Spring Data JPA, API REST)
Contexte
Vous êtes développeur backend dans une école. On vous demande de créer une API REST de gestion des étudiants avec Spring Boot.
Ce que vous devez livrer
Étape 1 — Créer le projet Spring Boot
- Créez un nouveau projet Spring Boot via Spring Initializr
- Choisissez les dépendances nécessaires pour :
- Créer une API REST
- Utiliser une base de données en mémoire (H2)
- Faire de la persistance JPA
- Valider les données d'entrée
Étape 2 — Créer l'entité Student
Créez une entité Student avec les champs suivants :
| Champ | Type | Contraintes |
|---|---|---|
| id | Long | Clé primaire, auto-générée |
| firstName | String | Obligatoire, entre 2 et 50 caractères |
| lastName | String | Obligatoire, entre 2 et 50 caractères |
| String | Obligatoire, format email valide, unique | |
| age | Integer | Obligatoire, entre 18 et 100 |
| program | String | Obligatoire (ex: "Informatique", "Génie logiciel") |
Étape 3 — Créer le Repository
- Créez une interface Repository pour l'entité
Student - Ajoutez une méthode pour vérifier si un email existe déjà
- Ajoutez une méthode pour chercher les étudiants par programme
Étape 4 — Créer le Service
Créez un Service qui implémente la logique métier suivante :
- Récupérer tous les étudiants
- Récupérer un étudiant par son ID — si l'étudiant n'existe pas, lancer une exception appropriée
- Créer un étudiant — vérifier que l'email n'est pas déjà utilisé avant de sauvegarder. Si l'email existe déjà, retourner une erreur 409 (Conflict)
- Modifier un étudiant — vérifier que l'étudiant existe, puis mettre à jour ses informations
- Supprimer un étudiant — vérifier que l'étudiant existe, puis le supprimer
Étape 5 — Créer le Controller REST
Créez un Controller qui expose les endpoints suivants :
| Méthode HTTP | URL | Action | Code de retour attendu |
|---|---|---|---|
| GET | /api/students | Liste de tous les étudiants | 200 OK |
| GET | /api/students/\{id\} | Détail d'un étudiant | 200 OK ou 404 Not Found |
| POST | /api/students | Créer un étudiant | 201 Created ou 409 Conflict |
| PUT | /api/students/\{id\} | Modifier un étudiant | 200 OK ou 404 Not Found |
| DELETE | /api/students/\{id\} | Supprimer un étudiant | 204 No Content ou 404 Not Found |
- Les données envoyées en POST et PUT doivent être validées automatiquement
- Si la validation échoue, retourner un code 400 Bad Request
Étape 6 — Configurer la base de données H2
- Configurez l'application pour utiliser une base de données H2 en mémoire
- Activez la console H2 pour pouvoir visualiser les données dans le navigateur
- La console doit être accessible à l'URL
/h2-console
Étape 7 — Tester tous les endpoints
Testez votre API avec Postman (ou un outil équivalent). Vous devez réaliser et capturer les tests suivants :
- Créer 3 étudiants (POST) — vérifier le code 201
- Lister tous les étudiants (GET) — vérifier qu'il y en a 3
- Récupérer un étudiant par ID (GET) — vérifier les données
- Modifier un étudiant (PUT) — changer son programme, vérifier la mise à jour
- Supprimer un étudiant (DELETE) — vérifier le code 204
- Relister tous les étudiants — vérifier qu'il n'en reste que 2
- Tester les erreurs :
- GET sur un ID inexistant → 404
- POST avec un email déjà utilisé → 409
- POST avec un email invalide → 400
- POST avec un prénom vide → 400
Exercices bonus
Bonus 1 — Recherche par programme
Ajoutez un endpoint qui permet de chercher les étudiants par programme :
GET /api/students/program/{program}
Par exemple : GET /api/students/program/Informatique retourne tous les étudiants en Informatique.
Bonus 2 — Statistiques
Ajoutez un endpoint qui retourne des statistiques :
GET /api/students/stats
Le JSON retourné doit contenir :
- Le nombre total d'étudiants
- La moyenne d'âge
- Le nombre d'étudiants par programme
Bonus 3 — Pagination
Modifiez le endpoint GET /api/students pour supporter la pagination :
GET /api/students?page=0&size=10&sort=lastName
Bonus 4 — Gestion d'erreurs centralisée
Créez un gestionnaire d'exceptions global qui :
- Retourne des messages d'erreur clairs en JSON
- Gère les cas : étudiant non trouvé (404), email dupliqué (409), validation échouée (400)
Format de réponse d'erreur attendu :
{
"status": 404,
"message": "Étudiant non trouvé avec l'ID: 99",
"timestamp": "2025-01-15T10:30:00"
}
Bonus 5 — Migration vers PostgreSQL
Remplacez H2 par PostgreSQL :
- Créez une base de données
studentdbdans PostgreSQL - Modifiez la configuration pour pointer vers PostgreSQL
- Vérifiez que les données persistent après un redémarrage de l'application
Livrables
| # | Livrable | Format |
|---|---|---|
| 1 | Code source complet du projet | Dépôt Git ou ZIP |
| 2 | Captures d'écran Postman des 10 tests (7 + 3 erreurs) | Images |
| 3 | Capture d'écran de la console H2 avec des données | Image |
| 4 | Au moins 2 exercices bonus complétés | Code |
| 5 | Réponses aux questions de révision (ci-dessous) | Document texte |
Questions de révision
Répondez à ces questions dans vos propres mots :
- Quelle est la responsabilité de chaque couche (Controller, Service, Repository) ?
- Pourquoi sépare-t-on le code en couches distinctes ?
- Quelle est la différence entre
@RestControlleret@Service? - Comment Spring Data JPA génère-t-il les requêtes SQL automatiquement ?
- Quel code HTTP doit-on retourner après une création réussie ? Après une suppression ?
- Pourquoi vérifier l'unicité de l'email dans le Service et pas seulement en base de données ?
- Que se passe-t-il si on envoie un JSON invalide au Controller ?
- Quelle est la différence entre
findById()qui retourne unOptionalet une méthode qui retourne directement l'objet ?
Critères d'évaluation
| Critère | Points |
|---|---|
| Architecture en couches correctement implémentée (Controller → Service → Repository) | 20% |
| Entité Student avec toutes les validations | 15% |
| Repository avec méthodes personnalisées | 10% |
| Service avec logique métier complète (vérifications, exceptions) | 20% |
| Controller avec les 5 endpoints CRUD fonctionnels | 20% |
| Tests Postman réussis (cas normaux + cas d'erreur) | 10% |
| Exercices bonus | 5% |
| Total | 100% |
Si vous êtes bloqué, ne restez pas plus de 15 minutes sur un problème. Consultez le TP3.1 pour voir comment c'est fait, puis revenez ici et essayez de le refaire sans regarder.