Introducción a Spring Boot y REST

Escribir una API HTTP en Java fue durante mucho tiempo un ejercicio de ensamblaje. Había que elegir un contenedor de servlets, instalarlo, describir la aplicación en un web.xml, conectar un framework web, injertarle un conversor JSON, declarar una fuente de datos, generar un .war y desplegarlo en un servidor de aplicaciones que había que mantener por separado. El primer {"message":"ok"} llegaba tras media jornada de fontanería, y esa fontanería no era de nadie: se copiaba de un proyecto a otro, con sus errores incluidos.

Spring Boot ha eliminado esa jornada. No inventando un nuevo framework (sigue siendo Spring), sino invirtiendo la carga de la configuración: en lugar de describir lo que quieres activar, declaras lo que quieres hacer, y el framework configura unos valores por defecto razonables que te deja sobrescribir. El servidor deja de ser un entorno en el que se despliega la aplicación y pasa a ser una dependencia de la aplicación. El entregable vuelve a ser un simple java -jar.

La segunda palabra del título es más engañosa que la primera. «REST» se ha convertido, en el uso corriente, en sinónimo de «JSON sobre HTTP». No es lo mismo. Una API que expone POST /api/getUtilisateurParId y responde 200 OK con {"erreur": "introuvable"} devuelve, efectivamente, JSON sobre HTTP, y no respeta prácticamente ninguna de las restricciones que dan valor a REST. La diferencia no es teórica: determina lo que una caché, un proxy, un cliente móvil o una biblioteca HTTP pueden hacer con tus respuestas sin saber nada de tu negocio.