Introduction à Spring Boot et REST

Écrire une API HTTP en Java a longtemps été un exercice d'assemblage. Il fallait choisir un conteneur de servlets, l'installer, décrire l'application dans un web.xml, câbler un framework web, y greffer un convertisseur JSON, déclarer une source de données, produire un .war, puis le déposer dans un serveur d'applications qu'il fallait maintenir séparément. Le premier {"message":"ok"} arrivait après une demi-journée de plomberie, et cette plomberie n'appartenait à personne : elle était recopiée d'un projet à l'autre, avec ses erreurs.

Spring Boot a supprimé cette journée. Pas en inventant un nouveau framework — c'est toujours Spring — mais en renversant la charge de la configuration : au lieu de décrire ce que vous voulez activer, vous déclarez ce que vous voulez faire, et le framework configure des valeurs par défaut raisonnables qu'il vous laisse écraser. Le serveur n'est plus un environnement où l'on dépose l'application, c'est une dépendance de l'application. Le livrable redevient un simple java -jar.

Le second mot du titre est plus trompeur que le premier. « REST » est devenu, dans l'usage courant, un synonyme de « JSON sur HTTP ». Ce n'est pas la même chose. Une API qui expose POST /api/getUtilisateurParId et répond 200 OK avec {"erreur": "introuvable"} renvoie bien du JSON sur HTTP, et ne respecte à peu près aucune des contraintes qui font l'intérêt de REST. La différence n'est pas théorique : elle décide de ce qu'un cache, un proxy, un client mobile ou une bibliothèque HTTP peuvent faire de vos réponses sans rien connaître de votre métier.