Introduction to Spring Boot and REST

Writing an HTTP API in Java used to be an exercise in assembly. You had to choose a servlet container, install it, describe the application in a web.xml, wire up a web framework, graft on a JSON converter, declare a data source, build a .war, and then drop it into an application server that you had to maintain separately. The first {"message":"ok"} arrived after half a day of plumbing, and that plumbing belonged to no one: it was copied from one project to the next, errors included.

Spring Boot eliminated that half day. Not by inventing a new framework — it's still Spring — but by reversing the burden of configuration: instead of describing what you want to enable, you declare what you want to do, and the framework configures sensible defaults that it lets you override. The server is no longer an environment into which you deploy the application; it is a dependency of the application. The deliverable becomes a simple java -jar.

The second word in the title is more misleading than the first. In everyday usage, "REST" has become a synonym for "JSON over HTTP." They are not the same thing. An API that exposes POST /api/getUtilisateurParId and answers 200 OK with {"erreur": "introuvable"} does return JSON over HTTP, and respects almost none of the constraints that make REST worthwhile. The difference is not theoretical: it determines what a cache, a proxy, a mobile client, or an HTTP library can do with your responses without knowing anything about your business domain.