Spring Boot desde cero

Cada pieza del framework, una por vez — Repository, Service, Controller — antes de verlas trabajar juntas.

16 aulas · 10 horas de práctica · en el navegador, sin instalar nada

Temario

  1. Una clase que guarda datos — Antes de cualquier anotación de Spring: una clase cuyo único trabajo es guardar y devolver datos. Esa idea, sola, ya tiene un nombre en el mundo del software — y entenderla aislada es la base de todo lo que sigue.
  2. @Repository de verdad — La misma clase de la aula anterior, ahora anotada: el contenedor la detecta y la construye sola, aunque todavía no exista ningún Service ni Controller que la use. Entender qué hace la anotación, aislada de todo lo demás.
  3. Una clase de lógica de negocio, sola — Otra clase en Java plano, sin ninguna anotación: un service que USA un repository (con un new manual, como ya sabés hacerlo) para agregarle una regla o un cálculo encima. Entender qué gana el programa al separar "guardar datos" de "decidir algo con ellos".
  4. @Service y la inyección por constructor — Las dos piezas juntas, por primera vez: un @Repository y un @Service que lo recibe por constructor, conectados automáticamente por el contenedor. Cada pieza ya la conocías por separado — acá solo se combinan.
  5. Taller — Reseñas recomendadas — Un repository y un service, de punta a punta, sin nada nuevo: armá vos mismo la clase completa que en la aula 4 ya viste combinada, en un dominio distinto.
  6. @RestController y @GetMapping: qué es una ruta — La capa que faltaba: exponer algo por HTTP, sin ninguna otra pieza de por medio. @RestController marca una clase como esa capa, @GetMapping mapea un método a una ruta, y Main.despachar(metodo, ruta, cuerpo) simula el pedido de un cliente real — sin @Service, sin @Repository, sin ningún @Autowired todavía.
  7. El controller conectado al service — Las tres piezas, juntas por primera vez: un @RestController que delega en un @Service, que a su vez usa un @Repository. Nada de esto es nuevo por separado —ya conocés cada pieza de aulas anteriores— lo nuevo es verlas trabajar en cadena, como una aplicación real.
  8. @RequestParam: datos desde la query string — @RequestParam lee un parámetro de la query string (lo que va después del ? en una URL). En este simulador siempre es obligatorio: si falta, la respuesta es 400 automáticamente, antes de que el método llegue a correr.
  9. @PathVariable: datos desde la ruta — @PathVariable extrae un segmento de la URL ({id} en /empleados/{id}), coaccionado al tipo del parámetro. A diferencia de @RequestParam (aula anterior), identifica QUÉ recurso puntual pedís, no cómo querés el resultado — un contraste corto y concreto entre las dos formas de leer datos de una URL.
  10. Taller: consulta de reservas — Nada nuevo: las cuatro piezas de las últimas cuatro aulas —Repository, Service, Controller, y una path variable— en un único endpoint de punta a punta, igual que lo armarías en una aplicación real chica.
  11. @RequestBody: crear un curso desde el cuerpo del pedido — El tercer y último mecanismo para meter datos en una ruta: @PostMapping mapea una petición POST, y @RequestBody deserializa el cuerpo del pedido a un record — con el mismo límite de siempre (records planos, un solo nivel) bien presente.
  12. Status codes: los límites reales, y por qué "que explote" no es diseño — En este simulador solo hay cuatro status codes posibles, y dos de ellos son puramente mecánicos: no podés elegir "responder 404" por una razón de negocio. La salida honesta es representar la ausencia con una respuesta 200 controlada, y reservar el 500 para lo genuinamente inesperado.
  13. Ambigüedad de beans: dos candidatos para el mismo tipo — Hasta ahora cada tipo pedido tenía exactamente un bean que lo resolvía. Cuando hay dos, el contenedor no adivina: rechaza el wiring con un error claro. Sin @Qualifier/@Primary en este simulador, la salida práctica es pedir el tipo CONCRETO en vez de la interfaz compartida.
  14. Diseño de una API REST, con las herramientas que hay — Rutas con sustantivos en plural, GET para leer y POST para crear — y una técnica real para "actualizar" cuando, como en este simulador, no hay PUT/PATCH/DELETE: modelar la acción como una sub-ruta POST.
  15. Cierre: un mini-servicio, de punta a punta — Todo el curso, en un solo ejemplo chico: @Repository guarda, @Service valida (con dos reglas de negocio, una de ellas inyectada por @Value), @RestController expone por HTTP — la misma separación de responsabilidades que vas a usar en cualquier proyecto Spring real. La preparación directa para "Spring Boot II".
  16. Taller — API de eventos — El taller más completo del curso: una API de reserva de eventos con cinco rutas, armada en cinco fases, que combinan TODO lo aprendido — @RequestBody para crear, @PathVariable y @RequestParam juntos en una acción como sub-ruta POST, respuestas 200 controladas para cada regla de negocio, y una dependencia resuelta por tipo concreto para evitar ambigüedad.

Es parte de