Spring Boot: el framework detrás de las apps Java

Inyección de dependencias y APIs REST, con un contenedor didáctico que resuelve el wiring al compilar en vez de reflexión en caliente.

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

Temario

  1. Por qué un framework — El armado manual de objetos (wiring) no escala: cuantas más clases dependen de otras, más lugares del programa tienen que repetir, a mano, el orden correcto de construcción. Un framework de inyección de dependencias automatiza justo eso.
  2. @Component, @Service y la inyección por constructor — La primera anotación que arma un bean solo, y la inyección por constructor con una única dependencia: el caso más simple del contenedor en acción.
  3. Varias dependencias, y cadenas — Un constructor puede pedir más de una dependencia a la vez, y una cadena de varios niveles (A necesita B, B necesita C y D) se resuelve exactamente igual: el contenedor arma el grafo completo y construye de adentro hacia afuera.
  4. @Autowired por campo, y @Value — Otra forma de inyectar una dependencia (por campo, no por constructor) y cómo inyectar un literal de configuración con @Value — con una limitación real de este simulador que hay que conocer.
  5. Ambigüedad y dependencias circulares — Dos formas en que el contenedor se niega a adivinar: dos beans candidatos para el mismo tipo (ambigüedad), y dos beans que se necesitan mutuamente (un ciclo). Cómo se ven los errores, y cómo evitarlos en la práctica.
  6. Capas de una aplicación: Service y Repository — Cómo se organiza una aplicación real en capas con responsabilidades separadas: un Repository que guarda datos, y un Service que aplica las reglas de negocio delegando en él. El Controller —la capa que falta— llega en la próxima aula, como @RestController.
  7. Taller — Sistema de descuentos — Cuatro componentes, una ambigüedad real para resolver (sin @Qualifier/@Primary), y una cadena de un nivel más para terminar de fijar cómo el contenedor arma el grafo completo.
  8. @RestController y @GetMapping — La capa que faltaba: exponer un Service por HTTP. @RestController marca la clase, @GetMapping mapea un método a una ruta, y @PathVariable extrae un segmento de la URL — coaccionado al tipo del parámetro.
  9. @RequestParam: query params, y el 400 cuando falta uno — @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 — y una diferencia honesta con Spring real que conviene conocer antes de que confunda.
  10. @PostMapping y @RequestBody — Crear un recurso: @PostMapping mapea una petición POST, y @RequestBody deserializa el cuerpo del pedido a un record — con el límite real de este simulador (records planos, un solo nivel) siempre presente.
  11. 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.
  12. Taller — API de biblioteca — Una API chica y completa: Controller -> Service -> Repository en memoria, GET para listar/leer, POST para crear, una acción como sub-ruta POST (prestar) — y las mismas respuestas controladas de la aula 10 para "no encontrado" y "ya prestado".
  13. 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.
  14. Taller — Catálogo con filtros — Dos endpoints de búsqueda con @RequestParam sobre un catálogo en memoria — un filtro de texto por categoría y uno numérico por precio mínimo — para terminar de fijar la diferencia entre el 400 mecánico de un query param que falta, y las respuestas 200 controladas que decide cada regla de negocio: un valor presente pero inválido, o una búsqueda sin resultados.
  15. Cierre: un mini-servicio, de punta a punta — Todo el curso, en un solo ejemplo chico: @Repository guarda, @Service valida (con una regla de negocio Y una configuración inyectada por @Value), @RestController expone por HTTP — la misma separación de responsabilidades que vas a usar en cualquier proyecto Spring real.
  16. Taller — Cierre: un endpoint nuevo, de punta a punta — La evaluación final del curso: agregar "devolver un libro" a la API del taller anterior, tocando los tres niveles a la vez — repositorio, reglas de negocio, y la ruta HTTP — exactamente el trabajo completo de agregar una funcionalidad a una app Spring real.

Es parte de