Spring et Spring Boot¶

Spring est le framework Java le plus utilisé pour écrire des services web, et Spring Boot est la façon moderne de s'en servir : cette partie t'apprend les deux en construisant une vraie API REST.

Spring Framework : un conteneur d'objets¶

En Rust ou en Python, c'est ton main qui assemble l'application : il ouvre le pool de connexions, le passe au service, qui est passé au routeur, puis il démarre le serveur. En Spring, tu déclares des classes avec des annotations, et c'est le framework qui les instancie et les relie entre elles.

C'est l'inversion de contrôle (IoC, Inversion of Control) : tu n'appelles plus le framework pour construire l'appli, c'est lui qui appelle ton code. Le cœur de Spring est donc un conteneur IoC, qu'on appelle aussi le contexte d'application (application context) :

• il trouve tes classes annotées (@Service, @RestController...) en parcourant tes paquets : le scan des composants ;
• il crée une instance de chacune : ces objets gérés par Spring s'appellent des beans ;
• il passe à chaque bean les autres beans dont il a besoin, en général via son constructeur : c'est l'injection de dépendances ;
• il gère leur cycle de vie : création au démarrage, fermeture propre à l'arrêt (comme un Drop géré pour toi).

@Service // (1)!
public class TodoService {

    private final TodoRepository repository;

    public TodoService(TodoRepository repository) { // (2)!
        this.repository = repository;
    }
}

1. « Ceci est un bean » : Spring le trouvera au démarrage et en créera une instance unique.
2. Spring voit ce constructeur, cherche un bean de type TodoRepository et le passe en argument. Tu n'écris nulle part new TodoService(...).

Autour de ce conteneur s'est construit un écosystème de modules qui s'y branchent tous de la même façon :

Ce cours utilise Spring Framework 7, avec Spring MVC et Spring Data JPA.

Spring Boot : Spring prêt à l'emploi¶

Spring seul demande beaucoup de configuration : quel serveur web, quel pool de connexions, quel convertisseur JSON, et comment les relier. Spring Boot fait ces choix à ta place, avec des valeurs par défaut raisonnables que tu peux toujours changer.

Les starters

Des dépendances Maven « tout-en-un ». spring-boot-starter-webmvc apporte d'un coup Spring MVC, le serveur Tomcat et Jackson (la bibliothèque JSON), dans des versions testées ensemble. Tu choisis des fonctionnalités, pas des bibliothèques une par une.

L'auto-configuration

Au démarrage, Spring Boot regarde ce qui est présent (classes dans le classpath, propriétés, beans déjà déclarés) et crée les beans qui manquent. Le pilote H2 est là et aucune base n'est configurée ? Il crée une base en mémoire et un pool de connexions. Jackson est là ? Il configure la conversion JSON. Tu as déclaré ton propre bean ? Il s'efface.

Le serveur embarqué

Pas de serveur d'applications à installer : Tomcat est une simple bibliothèque, démarrée par ton main. Toute l'appli tient dans un jar exécutable que tu lances avec java -jar, un peu comme le binaire produit par cargo build.

Les conventions

Configuration dans src/main/resources/application.properties, port 8080, scan des composants à partir du paquet de la classe principale, scripts SQL dans db/migration... Tu ne configures que ce qui s'écarte de la convention.

Les outils de production

Actuator expose /actuator/health (l'appli et sa base vont-elles bien ?) et d'autres endpoints de supervision ; toute propriété peut venir d'une variable d'environnement, ce qui colle parfaitement à Docker.

Ce cours utilise Spring Boot 4.1. Si tu lis des tutoriels en ligne, beaucoup visent Spring Boot 2 ou 3 : l'essentiel est identique, mais certains noms ont changé (le starter web s'appelait spring-boot-starter-web, les annotations de test ont changé de paquet).

Explicite chez toi, implicite chez Spring¶

Côté Rust, Axum et Actix sont des bibliothèques que tu assembles toi-même ; Flask joue le même rôle en Python. FastAPI en fait un peu plus (injection avec Depends, validation avec Pydantic). Django est le plus proche de Spring Boot : « piles incluses », conventions, ORM et migrations intégrés. Spring Boot va plus loin dans l'implicite : presque tout est découvert et câblé automatiquement.

L'avantage : très peu de code d'assemblage, et des choix cohérents d'un projet Spring à l'autre. L'inconvénient : quand quelque chose ne marche pas, il n'y a pas d'appel à suivre depuis main.

L'architecture en couches¶

Une application Spring classique se découpe en trois couches, chacune avec un rôle précis. Voici celles de l'API que tu vas construire :

flowchart LR
    client([Client HTTP])
    subgraph app [todo-api]
        controller["TodoController<br/>@RestController"]
        service["TodoService<br/>@Service"]
        repository["TodoRepository<br/>JpaRepository"]
        advice["ApiExceptionHandler<br/>@RestControllerAdvice"]
    end
    db[(H2 ou PostgreSQL)]
    client -->|requête JSON| controller
    controller -->|appel Java| service
    service --> repository
    repository -->|SQL| db
    controller -. exception .-> advice
    advice -. Problem Details .-> client

Chaque couche ne parle qu'à celle du dessous. Deux types d'objets circulent :

• l'entité Todo représente une ligne de la table todo ; elle ne sort jamais du service ;
• les DTO (Data Transfer Objects), écrits en record, décrivent ce qui entre et sort en JSON : CreateTodoRequest, UpdateTodoRequest, TodoResponse. Le format de l'API reste ainsi indépendant du schéma de la base.

Le code est rangé par fonctionnalité et non par couche : tout ce qui concerne les tâches vit dans le paquet xyz.dunkan.todo.todo, comme un module Rust qui regroupe un domaine.

Le fil rouge : une API de tâches¶

Toute cette partie construit une seule application, todo-api, une API REST qui gère une liste de tâches. Chaque chapitre lui ajoute une brique.

S'y ajoutent GET /hello, ton tout premier endpoint, et GET /actuator/health pour la supervision. Une règle métier donne un peu de matière : au plus 50 tâches non terminées à la fois (valeur configurable), sinon 409 Conflict.

Voici un vrai échange avec l'API terminée :

$ curl -i -X POST http://localhost:8080/api/todos -H 'Content-Type: application/json' -d '{"title": "Acheter du pain"}'
HTTP/1.1 201 
Location: http://localhost:8080/api/todos/1
Content-Type: application/json
Transfer-Encoding: chunked
Date: Wed, 21 Oct 2026 15:40:49 GMT

{"id":1,"title":"Acheter du pain","done":false,"createdAt":"2026-10-21T15:40:49.827439Z"}

Et une erreur de validation, au format standard Problem Details (RFC 9457) :

$ curl -X POST http://localhost:8080/api/todos -H 'Content-Type: application/json' -d '{"title": ""}'
{"detail":"Invalid request content.","instance":"/api/todos","status":400,"title":"Bad Request","errors":{"title":"must not be blank"}}

Le plan de cette partie¶

1. Premier projet : générer le projet, comprendre @SpringBootApplication, écrire GET /hello, produire un jar exécutable.
2. Injection de dépendances : beans, conteneur, injection par constructeur, portées et proxies.
3. API REST : TodoController, les records DTO, la validation, les codes HTTP et les erreurs Problem Details.
4. Configuration : application.properties, profils, @ConfigurationProperties, variables d'environnement.
5. Base de données (JPA) : l'entité Todo, JpaRepository, les requêtes dérivées, les transactions et les migrations Flyway.
6. Tests : tests unitaires avec Mockito, @WebMvcTest, @DataJpaTest et un test de bout en bout.
7. Déployer : profil de production, PostgreSQL, image Docker et Actuator.

Le projet complet¶

Le code final, compilé et testé, est téléchargeable :

Télécharger todo-api.zip

Il te faut seulement un JDK 25 : le wrapper Maven ./mvnw télécharge le reste.

cd todo-api
./mvnw verify            # compile et lance les 20 tests
./mvnw spring-boot:run   # démarre l'API sur http://localhost:8080

Le fichier README.md du projet liste un exemple curl pour chaque endpoint.

À retenir¶

• Spring Framework est un conteneur IoC : il crée tes objets (les beans) et leur injecte leurs dépendances.
• Les annotations sont lues à l'exécution par réflexion, et des proxies ajoutent des comportements comme les transactions.
• Spring Boot ajoute des starters, l'auto-configuration, un Tomcat embarqué et des conventions : très peu de code d'assemblage.
• Ce qui est explicite dans main avec Axum ou FastAPI est implicite chez Spring : en cas de souci, lis les logs ou lance avec --debug.
• Une appli Spring se découpe en couches controller → service → repository, et n'expose jamais ses entités, seulement des DTO.
• Toute cette partie construit la même API todo-api, téléchargeable en entier.