En este punto, el controlador de nuestra API empieza a hacer demasiadas cosas: recibe peticiones, extrae datos, los valida y los procesa, para finalmente montar la respuesta. Ser el encargado de recibir los datos no significa que tenga que gestionarlos ni implementar toda la lógica. Siguiendo el Principio de Responsabilidad Única, y la Arquitectura por capas, es el momento de sacar del controlador la lógica de negocio y crear una nueva pieza con una responsabilidad más clara: un Service. ...

Si nuestros endpoints devuelven String o Map, ya contamos con una API plenamente funcional, pero no es la mejor solución. El problema es que la estructura de la respuesta está demasiado abierta, lo que la hace más frágil y difícil de mantener. Para especificar de forma clara el contrato de la API, es conveniente introducir en este punto los DTO (Data Transfer Objects). El problema de devolver un Map Hasta ahora, nuestra API devuelve datos, pero sin estar representados de forma explícita y mantenible. Spring serializa el Map sin problema a JSON, pero presenta una serie de inconvenientes que lo hacen poco adecuado para una API que empieza a evolucionar: ...

Hasta ahora nuestro código está devolviendo un String de forma directa que Spring Boot convierte automáticamente en una respuesta HTTP completa. Ésta, por defecto, incluye un código de estado (200 OK) y un cuerpo con el mensaje. El siguiente paso para mejorar el diseño de nuestra API es controlar completamente la respuesta y adaptarla a nuestra lógica, para lo que contamos con la clase ResponseEntity. Qué es una respuesta HTTP Una respuesta HTTP es el mensaje que devuelve el servidor cuando un cliente realiza una petición a una API. Esta respuesta incluye principalmente un código de estado, que indica si la operación ha sido correcta o ha ocurrido algún problema, y un cuerpo con los datos que queremos devolver. ...

Una API es la puerta de entrada a nuestra aplicación: recibe peticiones desde el exterior, extrae los datos que le envían, ejecuta la lógica necesaria y devuelve una respuesta. Hasta ahora, en nuestra API HelloWorld solo recibimos peticiones y damos una respuesta. El siguiente paso es permitir que un cliente nos pase información a través de la URL. Formas en las que una API puede recibir datos El componente encargado de extraer los datos de la petición es el controlador. En una API HTTP, éstos pueden llegar al endpoint de varias maneras según su finalidad: ...

El Principio de Responsabilidad Única nos dice que clases y funciones deben tener una responsabilidad clara y específica para conseguir código de mayor calidad. Pero podemos ir un paso más allá aplicando este mismo criterio para organizar una aplicación completa, agrupando componentes según su responsabilidad y definiendo cómo se comunican entre sí. Este enfoque permite estructurar el sistema de forma que sea más robusto, mantenible y fácil de evolucionar. En qué consiste La arquitectura por capas consiste en organizar una aplicación en módulos que comparten una responsabilidad clara, estableciendo además una dirección definida en sus dependencias. Cada capa se comunica únicamente con las capas adyacentes. ...