Projet : l'API de la Librairie

Cinq livres plus tôt, la Librairie du Campus n'était qu'une page HTML. Elle est devenue une application complète : un client Vue, écrit au livre précédent, et un serveur Spring Boot, écrit dans celui-ci, avec sa base PostgreSQL, ses comptes du personnel, ses tests et son image Docker. Ce dernier chapitre ne présente pas d'outil nouveau. Il fait ce que l'on fait avant de livrer un projet : vérifier que le serveur Java tient exactement le contrat de l'API qu'il remplace, faire tourner l'application entière comme un client le ferait, chercher ce qui casserait sous la charge, et relire l'ensemble.

Nous y découvrirons un dernier défaut, sérieux, que ni les tests ni l'usage ordinaire n'avaient montré : deux clients qui achètent le même livre au même instant peuvent se voir vendre plus d'exemplaires qu'il n'y en a.

Le projet code/ch12/librairie part de celui du chapitre 11. Les relevés de ce chapitre ont été produits avec ce projet lancé par ./mvnw spring-boot:run (base de développement neuve à chaque scénario), le serveur d'essai serveur.mjs du livre Vue, et Chromium piloté par Playwright.

12.1 Le contrat tenu

Le serveur d'essai fixait un contrat : trois adresses, des formes JSON, des codes de statut et des messages d'erreur, sur lesquels l'application Vue s'appuie. On lance les deux serveurs côte à côte (le serveur d'essai sur le port 8001, Spring Boot sur le port 8000) et on leur envoie les mêmes requêtes. Pour chacune, la réponse du serveur d'essai, puis celle de Spring Boot, puis le statut ; les deux premières listes sont coupées :

### GET /api/livres?q=PRINCE
--- 8001
[{"isbn":"9782956300052","titre":"Le Petit Prince","auteur":"A. de Saint-Exupéry","rayon":"Littérature","prix":8.5,"image":"images/prince.svg","nouveaute":false,"stock":25}]
[200]
--- 8000
[{"isbn":"9782956300052","titre":"Le Petit Prince","auteur":"A. de Saint-Exupéry","rayon":"Littérature","prix":8.50,"image":"images/prince.svg","nouveaute":false,"stock":25}]
[200]
### GET /api/livres/123
--- 8001
{"erreur":"Aucun livre d’ISBN 123."}
[404]
--- 8000
{"detail":"Aucun livre d’ISBN 123.","instance":"/api/livres/123","status":404,"title":"Livre introuvable","erreur":"Aucun livre d’ISBN 123."}
[404]
### POST /api/commandes (valide)
--- 8001
{"numero":1001,"total":19}
[201]
--- 8000
{"numero":1001,"total":19.00}
[201]
### POST /api/commandes (invalide)
--- 8001
{"erreurs":["Stock insuffisant pour « Physique générale » (0 en stock)."]}
[400]
--- 8000
{"detail":"La commande ne peut pas être acceptée.","instance":"/api/commandes","status":400,"title":"Commande refusée","erreurs":["Stock insuffisant pour « Physique générale » (0 en stock)."]}
[400]
### POST /api/commandes (pas du JSON)
--- 8001
{"erreurs":["Le corps de la requête n’est pas du JSON valide."]}
[400]
--- 8000
{"detail":"Le corps de la requête n’est pas du JSON valide.","instance":"/api/commandes","status":400,"title":"Requête invalide","erreurs":["Le corps de la requête n’est pas du JSON valide."]}
[400]

Le filtre par rayon donne les deux mêmes livres, et une commande dont tous les champs sont faux, les quatre mêmes messages dans le même ordre (celui des champs du record, chapitre 4). Trois différences restent, toutes voulues :

• les montants s'écrivent avec deux décimales (8.50, 19.00) : ce sont des BigDecimal à deux chiffres après la virgule. Pour JSON, c'est le même nombre ; l'application Vue les formate de toute façon en 8,50 € ;
• les erreurs suivent la RFC 9457 (type, title, status, detail, instance), et gardent les champs erreur ou erreurs que lit le client : le contrat est étendu, pas changé ;
• les erreurs de champs ont le titre « Requête invalide », les refus du catalogue « Commande refusée » : le client peut les distinguer.

Le serveur Java ajoute aussi au contrat ce que le serveur d'essai ne savait pas faire : la gestion du catalogue et la liste des commandes, réservées au personnel (chapitre 8).