Introdução ao Spring Boot e REST

Escrever uma API HTTP em Java foi, por muito tempo, um exercício de montagem. Era preciso escolher um contêiner de servlets, instalá-lo, descrever a aplicação em um web.xml, ligar um framework web, acoplar um conversor JSON, declarar uma fonte de dados, gerar um .war e depois implantá-lo em um servidor de aplicações que precisava ser mantido separadamente. O primeiro {"message":"ok"} chegava depois de meio dia de encanamento, e esse encanamento não pertencia a ninguém: era copiado de um projeto para outro, com seus erros.

O Spring Boot eliminou esse dia. Não inventando um novo framework — continua sendo Spring — mas invertendo o peso da configuração: em vez de descrever o que você quer ativar, você declara o que quer fazer, e o framework configura valores padrão razoáveis que ele deixa você sobrescrever. O servidor deixa de ser um ambiente onde se implanta a aplicação e passa a ser uma dependência da aplicação. O artefato volta a ser um simples java -jar.

A segunda palavra do título é mais enganosa que a primeira. «REST» tornou-se, no uso corrente, sinônimo de «JSON sobre HTTP». Não é a mesma coisa. Uma API que expõe POST /api/getUtilisateurParId e responde 200 OK com {"erreur": "introuvable"} realmente devolve JSON sobre HTTP, e não respeita praticamente nenhuma das restrições que dão interesse ao REST. A diferença não é teórica: ela decide o que um cache, um proxy, um cliente mobile ou uma biblioteca HTTP podem fazer com as suas respostas sem conhecer nada do seu negócio.