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:

1. No está tipado: No existe una estructura definida que indique qué campos debe contener la respuesta.
2. Sin documentación clara: la forma del JSON no queda reflejada en ningún tipo o clase, dificultando entender qué devuelve realmente el endpoint.
3. Fácil equivocarse en claves: las claves son cadenas de texto, por lo que un error tipográfico puede pasar desapercibido hasta tiempo de ejecución.
4. Un cambio de nombre rompe contratos con clientes fácilmente: modificar una clave puede afectar a clientes que dependen de esa estructura sin que el compilador detecte el problema.
5. Perdemos claridad y el apoyo del compilador durante el desarrollo: no contamos con autocompletado ni comprobaciones de tipos al trabajar con los datos.
6. No es escalable: a medida que la respuesta crece, el Map se vuelve más difícil de leer, mantener y evolucionar.

El problema no es que falle, es que la estructura de la respuesta queda implícita, dispersa y demasiado abierta.

Qué es un DTO

Un DTO (Data Transfer Object) es un objeto cuyo objetivo es transportar datos entre capas o entre sistemas. En una API, uno de sus usos más habituales es representar de forma explícita los datos que enviamos o recibimos en los diferentes endpoints.

Son objetos simples cuya función es representar datos con una estructura clara y fija, sin contener ninguna lógica de negocio. De esta forma, la estructura de la respuesta queda definida de manera explícita y controlada.

Primer DTO en nuestra API

La respuesta que devolvemos actualmente ya está serializada en un JSON con el siguiente contenido:

{
    "message": "Hello Juan from Spring Boot!",
    "name": "Juan",
    "timestamp": "2026-04-04T11:30:38.578535500Z"
}

Spring la está formando a partir de un Map en el endpoint:

1
2
3
4
5
6
7
8
9

@GetMapping("/hello")  
public ResponseEntity<Map<String, String>> hello(@RequestParam(defaultValue = "World") String name) {  
    Map<String, String> content = Map.of(  
            "message", "Hello " + name + " from Spring Boot!",  
            "name", name,  
            "timestamp", Instant.now().toString()  
    );  
    return ResponseEntity.ok(content);  
}

Un primer DTO para la respuesta de nuestro endpoint podría ser el siguiente, incluyendo un atributo por cada campo que queremos devolver:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class HelloResponseDto {  
  
    private String message;  
    private String name;  
    private String timestamp;  
  
    public HelloResponseDto(String message, String name, String timestamp) {  
        this.message = message;  
        this.name = name;  
        this.timestamp = timestamp;  
    }  
  
    public String getMessage() {  
        return message;  
    }  
  
    public String getName() {  
        return name;  
    }  
  
    public String getTimestamp() {  
        return timestamp;  
    }  
  
}

Quedando el endpoint de la siguiente manera, sin alterar la respuesta de la petición:

1
2
3
4
5
6
7
8
9

@GetMapping("/hello")  
public ResponseEntity<HelloResponseDto> hello(@RequestParam(defaultValue = "World") String name) {  
    HelloResponseDto content = new HelloResponseDto(  
            "Hello " + name + " from Spring Boot!",  
            name,  
            Instant.now().toString()  
    );  
    return ResponseEntity.ok(content);  
}

Ahora la estructura de la respuesta queda definida de forma explícita en un tipo Java, facilitando su comprensión y evolución.

Usando record de Java

Como el objeto HelloResponseDto solo transporta datos, Java ofrece una forma más compacta de representarlo: record. Un record define datos inmutables, reduce el código repetitivo y encaja muy bien en objetos simples de transporte.

Podríamos redefinir la clase HelloResponseDto de la siguiente manera:

1

public record HelloResponseDto(String message, String name, String timestamp) {  }

El endpoint no necesita modificarse, ya que el record implementa automáticamente el constructor y los métodos de acceso.

Ventajas frente a Map

1. Un Map describe datos de forma improvisada; un DTO describe datos de forma intencional.
2. Más claridad: el nombre HelloResponseDto expresa qué estamos devolviendo.
3. Estructura explícita: los campos están definidos en un tipo.
4. Menos errores involuntarios en el desarrollo: no dependemos de escribir claves String a mano
5. Mejor mantenimiento: el cambio está centralizado.
6. Mejor evolución: más fácil añadir nuevos campos sin desordenar el controlador

Evolución de nuestra API

En el endpoint /hello comenzamos devolviendo un String, luego mejoramos la respuesta con ResponseEntity. Después pasamos a devolver un JSON. Y ahora damos un paso más definiendo explícitamente su estructura mediante DTOs. De esta forma, el contrato con los clientes se vuelve más robusto, mantenible y fiable, sentando además una base sólida para seguir evolucionando la API.

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.

200 OK
Content-Type: application/json

{ "Hello World from Spring Boot!" }

En nuestro caso:

• 200 OK: la petición se ha procesado correctamente.
• Content-Type: indica el tipo de contenido, JSON en este caso.
• Hello World from Spring Boot!: cuerpo de la respuesta, un String que Spring Boot serializa automáticamente.

Este concepto es importante porque, a medida que nuestra API evolucione, no solo devolveremos texto, sino también distintos códigos HTTP y estructuras más completas, y ahí es donde entra ResponseEntity.

Controlando la respuesta con ResponseEntity

ResponseEntity es una clase de Spring que permite controlar completamente la respuesta HTTP que devuelve nuestra API. En lugar de devolver solo el contenido, podemos definir también el código de estado, las cabeceras y el cuerpo de la respuesta.

Hasta ahora, nuestro controlador devuelve un String directamente:

1
2
3
4

@GetMapping("/hello")  
public String hello(@RequestParam(defaultValue = "World") String name) {  
    return "Hello " + name + " from Spring Boot!";  
}

Podemos usar ResponseEntity para indicar explícitamente el código HTTP que debe incluir:

1
2
3
4
5

@GetMapping("/hello")  
public ResponseEntity<String> hello(@RequestParam(defaultValue = "World") String name) {  
    String content = "Hello " + name + " from Spring Boot!";  
    return ResponseEntity.ok(content);  
}

En este caso seguimos devolviendo el mismo contenido, pero ahora estamos construyendo explícitamente una respuesta HTTP, algo fundamental cuando queramos devolver errores (códigos 400 o 404), recursos creados ( código 201) o respuestas más complejas.

Completando la respuesta con un JSON

Otra mejora para conseguir una respuesta más adecuada para una API es devolver el contenido como un objeto JSON bien estructurado.

1
2
3
4
5
6
7

@GetMapping("/hello")  
public ResponseEntity<Map<String, String>> hello(@RequestParam(defaultValue = "World") String name) {  
    Map<String, String> content = Map.of(  
            "message", "Hello " + name + " from Spring Boot!"  
    );  
    return ResponseEntity.ok(content);  
}

En el caso de un String simple puede parecer de poco interés, pero lo habitual será que la respuesta incluya mucha más información, de forma que un JSON permita estructurar mejor los datos.

1
2
3
4
5
6
7
8
9

@GetMapping("/hello")  
public ResponseEntity<Map<String, String>> hello(@RequestParam(defaultValue = "World") String name) {  
    Map<String, String> content = Map.of(  
            "message", "Hello " + name + " from Spring Boot!",  
            "name", name,  
            "timestamp", Instant.now().toString()  
    );  
    return ResponseEntity.ok(content);  
}

Si levantamos el servidor y, como venimos haciendo, realizamos una petición desde el navegador, obtendremos la respuesta con el JSON completo.

Validando la API con los test

Una vez más, debemos usar los test para validar los cambios realizados. Hasta ahora, el contrato de nuestra API incluía una respuesta HTTP formada automáticamente con un único String en el cuerpo. Pero ahora, la respuesta es mucho más completa, con otro formato y con el mensaje dentro de un JSON.

Si ejecutamos los test existentes, éstos fallarán, indicando que hemos roto ese contrato.

Cambio de contrato con los clientes

Si nuestra API se encontrase en producción, esto nos indicaría que tendríamos un problema que podríamos afrontar con dos planteamientos:

• Obligar a todos nuestros clientes a actualizar sus desarrollos para adaptarse al nuevo formato de respuesta.
• Versionar nuestra API, manteniendo el endpoint actual sin modificar y publicar el nuevo en una nueva ruta, permitiendo a los clientes migrar de forma progresiva.

Evolucionando los tests

Para validar el nuevo desarrollo, adaptamos los test a la nueva respuesta del endpoint.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

@Test  
void helloWithoutParamReturnsDefaultValue() throws Exception {  
    mockMvc.perform( get("/hello") )  
            .andExpect( status().isOk() )  
            .andExpect( jsonPath("$.message").value("Hello World from Spring Boot!") )  
            .andExpect( jsonPath("$.name").value("World") )  
            .andExpect( jsonPath("$.timestamp").isString() );  
}  
  
@Test  
void helloWithParamReturnsCustomName() throws Exception {  
    mockMvc.perform(get("/hello").param("name", "Juan"))  
            .andExpect(status().isOk())  
            .andExpect(jsonPath("$.message").value("Hello Juan from Spring Boot!"))  
            .andExpect(jsonPath("$.name").value("Juan"))  
            .andExpect(jsonPath("$.timestamp").isString());  
}

jsonPath("$.message") indica a MockMvc que acceda al campo message del JSON devuelto:

• $: representa la raíz del JSON
• $.message: accede al campo message
• .value(...): comprueba que ese campo tiene el valor esperado

Por lo tanto, permite validar un campo concreto dentro del JSON que devuelve la API y verifica que:

• La respuesta tiene formato JSON
• Existe el campo message
• Su valor es exactamente el esperado en cada caso

Este enfoque permite validar respuestas más complejas de forma precisa, comprobando cada campo individualmente en lugar de comparar todo el contenido como una cadena de texto, lo que hace los tests más robustos y fáciles de mantener.

Conclusiones

Mejorando la respuesta de nuestra API, pasando de devolver texto simple a diseñar respuestas HTTP más completas, estamos evolucionándola de forma natural para conseguir un resultado más profesional. Además, con el trabajo continuo con los test, conseguimos validar el contrato que establecemos con nuestros clientes, de forma que podamos realizar esa evolución con seguridad.

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:

1. En la URL como parámetros
2. En la URL como parte de la ruta
3. En el cuerpo de la petición
4. En las cabeceras de la petición
5. En cookies
6. Como formularios
7. Como ficheros

Vamos a ver la primera y más sencilla de ellas: recibir datos como parámetros de la URL.

Primer dato de entrada en nuestra API

Nuestra API de momento, está devolviendo un saludo genérico. A partir de aquí, empezamos a construir APIs que reaccionan a lo que les envía el cliente.

http://localhost:8080/hello?name=Juan

Para recibirlo en el controlador y poder utilizarlo, incorporamos un parámetro con el mismo nombre al método del endpoint y lo anotamos con @RequestParam. De esta forma Spring Boot extrae automáticamente el valor de la URL y lo pasa como argumento al método.

1
2
3
4

@GetMapping("/hello")  
public String hello(@RequestParam String name) {  
    return "Hello " + name + " from Spring Boot!";
}

Si desplegamos la aplicación y probamos desde el navegador, vemos el resultado:

Pero, ¿y si no incluimos el parámetro name en la URL?

Parámetros opcionales

Con la configuración actual, la aplicación está esperando siempre recibir el parámetro name en la petición, devolviendo un error de no ser así.

Para evitarlo, podemos marcar los parámetros como opcionales con la propiedad required de la siguiente manera:

1
2
3
4
5
6
7

@GetMapping("/hello")  
public String hello(@RequestParam(required = false) String name) {  
    if( name == null ) {  
        return "Hello World from Spring Boot!";  
    }  
    return "Hello " + name + " from Spring Boot!";  
}

En este caso, si no se envía el parámetro, Spring asigna el valor null.

Valores por defecto

La anotación cuenta con la propiedad defaultValue que nos permite simplificar la lógica en el controlador, fijando un valor por defecto si no se informa el parámetro, en cuyo caso Spring asume automáticamente que se trata de un parámetro opcional. Cuando usamos defaultValue, Spring considera automáticamente que el parámetro es opcional, por lo que no es necesario indicar required = false.

1
2
3
4

@GetMapping("/hello")  
public String hello(@RequestParam(defaultValue = "World") String name) {  
    return "Hello " + name + " from Spring Boot!";  
}

Cuando usar parámetros en la URL

Los @RequestParam se utilizan cuando queremos recibir datos simples en la URL, normalmente para:

• filtros
• búsquedas
• valores opcionales

Los tests como red de seguridad ante cambios

Cada vez que cambiamos el comportamiento de un endpoint, los tests nos ayuda a comprobar si de cara al cliente el cambio ha sido transparente. No solo validan el código, también documentan cómo debe comportarse la API.

Si lanzamos los tests que ya habíamos implementado, vemos que siguen ejecutándose correctamente. Esto ocurre porque hemos mantenido el comportamiento por defecto gracias al uso de defaultValue.

1
2
3
4
5
6

@Test  
void helloEndpointReturnsHelloWorld() throws Exception {  
    mockMvc.perform( get("/hello") )  
            .andExpect( status().isOk() )  
            .andExpect( content().string("Hello World from Spring Boot!") );  
}

Los tests evolucionan con el código

Unos test útiles y completos deben cubrir los distintos escenarios posibles, y deben ampliarse junto con el código de la API. Nuestro test cubre el comportamiento por defecto, pero deberemos completarlo ahora para el caso de recibir un parámetro.

1
2
3
4
5
6

@Test  
void helloWithParamReturnsCustomName() throws Exception {  
    mockMvc.perform(get("/hello").param("name", "Juan"))  
            .andExpect(status().isOk())  
            .andExpect(content().string("Hello Juan from Spring Boot!"));  
}

Elementos nuevos que usa el test

Herramientas para simular peticiones HTTP

• param(): Spring Boot añade este parámetro a la URL como si el cliente lo hubiera enviado en la petición real.

Nombres que reflejen intención

Adicionalmente, para reflejar mejor qué caso valida cada test, actualizamos también el nombre del test previo:

1
2
3
4
5
6

@Test  
void helloWithoutParamReturnsDefaultValue() throws Exception {  
    mockMvc.perform( get("/hello") )  
            .andExpect( status().isOk() )  
            .andExpect( content().string("Hello World from Spring Boot!") );  
}

Lanzamos de nuevo la ejecución de los tests y comprobamos que finalizan correctamente.

Conclusiones

Las APIs son las puertas de entrada a nuestras aplicaciones por lo que será habitual recibir datos en alguno de los formatos y por alguna de las vías que proporciona Spring Boot. Los parámetros en la URL son una de las más sencillas y útiles. A partir de aquí, iremos incorporando nuevas formas de recibir datos en nuestra API a medida que evolucionamos sus funcionalidades.

También, cada vez que cambiamos el comportamiento de nuestra API, los tests nos ayudan a validar y revisar los cambios de forma que podamos detectar si estamos modificando algún caso de uso que no teníamos contemplado, pero para que sigan siendo útiles, deben completarse a medida que ampliamos nuestra API.

Con las pruebas y los tests sucede algo similar. Durante el desarrollo vamos lanzando comprobaciones manuales y, cuando vemos que todo más o menos funciona, lo damos por válido. Puede que incluso documentemos alguna de ellas, pero suele percibirse como otra tarea pesada que no siempre motiva y que intentamos quitarnos de encima cuanto antes.

Sin embargo, al igual que un buen análisis, diseño y planificación nos ahorra tiempo y evita errores a largo plazo, un buen diseño de los casos de prueba y su automatización contribuye a obtener un mejor resultado final. Además, nos garantiza que podremos detectar rápidamente si un nuevo evolutivo introduce errores que no habíamos contemplado.

Testing en Spring Boot

Spring Boot incorpora de serie varias herramientas que facilitan enormemente la implementación de los primeros tests. Entre ellas destacan:

• JUnit 5: es un framework de testing que nos permite definir y ejecutar test en Java mediante anotaciones como @Test.
• Spring Boot Test: conjunto de utilidades que facilita probar aplicaciones Spring cargando el contexto, inyectando dependencias y simulando peticiones HTTP.
• Maven configurado para ejecutar test: Maven ejecuta automáticamente los test durante el ciclo de compilación, fallando el proceso si alguno no pasa y evitando la generación de artefactos incorrectos.

Primer test de Hello World

Para implementar los primeros tests nos vamos a basar en el Hello World que desarrollamos en el artículo anterior y que ya hemos compilado con Maven.

Al crear la estructura básica del proyecto con Spring Initializr e incluir la dependencia Spring Web, ya deberíamos tener en el pom.xml la dependencia spring-boot-starter-webmvc-test, que nos proporciona todo lo necesario para estos primeros tests.

La aplicación arranca

Se trata de un test de contexto, anotado con @SpringBootTest, que ya tendremos creado automáticamente en la estructura del proyecto dentro de la carpeta src/test. En nuestro caso se denomina SpringBootHelloWorldApplicationTests.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.junit.jupiter.api.Test;  
import org.springframework.boot.test.context.SpringBootTest;  
  
@SpringBootTest  
class SpringBootHelloWorldApplicationTests {  
  
    @Test  
    void contextLoads() {  
    }  
  
}

Este test no contiene lógica alguna, pero precisamente ahí reside su valor. Comprueba que el contexto de Spring arranca correctamente y, si falla, indica que existe un problema grave en la configuración de la aplicación.

Testear un endpoint sencillo: Hello World

El siguiente paso es diseñar e implementar un test para nuestro endpoint /hello. Aunque se trata de un endpoint muy sencillo, ya podemos validar tres aspectos básicos:

1. Que el endpoint existe bajo la URL
2. Que responde con código HTTP 200
3. Que devuelve el contenido esperado

El código del test es el siguiente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.junit.jupiter.api.Test;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.boot.test.context.SpringBootTest;  
import org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc;  
import org.springframework.test.web.servlet.MockMvc;  
  
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;  
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;  
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;  
  
@SpringBootTest  
@AutoConfigureMockMvc  
public class HelloControllerTest {  
  
    @Autowired  
    private MockMvc mockMvc;  
  
    @Test  
    void helloEndpointReturnsHelloWorld() throws Exception {  
        mockMvc.perform( get("/hello") )  
                .andExpect( status().isOk() )  
                .andExpect( content().string("Hello World from Spring Boot!") );  
    }  
}

Elementos que se usan en el test

Anotaciones de Spring y JUnit:

• @Autowired: le indica a Spring que inyecte automáticamente una instancia de MockMvc en el test.
• @Test: anotación de JUnit 5 que marca un método como test y permite que el framework lo ejecute durante la fase de testing.
• @AutoConfigureMockMvc: indica a Spring Boot que configure automáticamente MockMvc, permitiéndonos simular peticiones HTTP a los endpoints sin arrancar un servidor real.

Herramientas para simular peticiones HTTP:

• MockMvc: utilidad de Spring para simular llamadas HTTP (GET, POST, etc.) contra los controladores y verificar sus respuestas.
• get(): construye una petición HTTP de tipo GET contra la ruta indicada, en nuestro ejemplo /hello.
• perform(): ejecuta la petición HTTP simulada y definida previamente. Devuelve el resultado para poder hacer comprobaciones sobre la respuesta.

Validación de la respuesta:

• andExpect(): define una expectativa sobre la respuesta obtenida; si no se cumple, el test falla.
• status() e isOk(): comprueban que el código de estado HTTP de la respuesta sea 200 (OK).
• content(): permite validar el contenido del cuerpo de la respuesta.

Ejecutar los test con Maven

Una vez configurados los tests, podemos ejecutarlos desde el propio IDE o, al igual que para la construcción del artefacto, desde la línea de comandos utilizando Maven.

Desde un terminal, situados en la carpeta raíz del proyecto, ejecutamos:

mvn test

Maven compilará el código y lanzará todos los tests definidos en el proyecto, mostrando el resultado en la consola.

Si forzamos un error -por ejemplo, cambiando el texto esperado en el cuerpo de la respuesta- y ejecutamos de nuevo el comando, veremos cómo el test falla. La salida por consola indicará qué test ha fallado, qué se esperaba que ocurriera y cuál ha sido el resultado real, proporcionando información muy útil para entender el problema y corregirlo.

Conclusiones

En este artículo hemos dado el primer paso en la incorporación de tests automatizados a nuestra API Spring Boot. Partiendo de un ejemplo muy sencillo, hemos visto cómo validar que la aplicación arranca correctamente y cómo comprobar el comportamiento de un endpoint HTTP mediante tests automatizados.

Hasta ahora, en la serie hemos creado una API básica, la hemos compilado con Maven y la hemos preparado para su ejecución. Con estos primeros tests añadimos una capa fundamental de seguridad que nos permitirá evolucionar el código con mayor confianza.

En los siguientes artículos iremos ampliando este enfoque, incorporando tests más completos y sentando las bases para su integración en un proceso de integración continua (CI), donde estos tests se ejecutarán automáticamente en cada cambio del código.

Objetivo

Para ejemplificar esta simplicidad, se desarrolla un servicio web con un solo endpoint que devuelva un mensaje de Hello World.

Creación del proyecto base

El ecosistema Spring cuenta con una herramienta que facilita la creación de la estructura base del proyecto, se trata de Spring initializr.

Ésta genera la estructura básica de un proyecto Spring Boot en segundos. Permite seleccionar la versión de Spring, el lenguaje, el build system (Maven o Gradle) y las dependencias necesarias, creando automáticamente un proyecto listo para abrir en cualquier IDE.

Para el Hello World solo es necesario incluir la dependencia de Spring Web.

Al pulsar en GENERATE se descarga un fichero comprimido con el proyecto que cuenta con la estructura y componentes mínimos para importar en cualquier IDE y desplegar la aplicación.

Este proyecto se puede importar o abrir desde cualquier IDE que cuente con soporte para desarrollo de aplicaciones Spring Boot. Para el ejemplo, se utiliza IntelliJ.

Creación del controlador

Un controlador en Spring es el componente encargado de recibir las peticiones HTTP, procesarlas y devolver una respuesta. Actúa como punto de entrada de la aplicación, mapeando URLs y métodos HTTP (GET, POST, etc.) a métodos Java. Separa la lógica de exposición de la API del resto de la aplicación y su lógica, que se conformará con otro tipo de componentes que se utilizarán para obtener respuestas más complejas.

Anotaciones RestController y GetMapping

Las anotaciones en Spring son etiquetas que se colocan sobre clases y métodos para decirle al framework qué papel cumple cada uno y cómo deben actuar, sin necesidad de escribir código adicional de configuración.

RestController

Es la anotación que marca una clase como un componente que expone endpoints REST. Todo lo que devuelvan sus métodos será serializado automáticamente (Strings, JSONs, etc.).

GetMapping

Asocia un método a una petición HTTP GET y a una ruta concreta que se debe especificar como un parámetro de la propia anotación.

Ejemplo completo

Para disponer de un endpoint bajo la ruta /hello que responda a una petición GET, bastaría con completar el Controlador HelloController de la siguiente forma:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.springframework.web.bind.annotation.GetMapping;  
import org.springframework.web.bind.annotation.RestController;  
  
@RestController  
public class HelloController {  
  
    @GetMapping("/hello")  
    public String hello() {  
        return "Hello World from Spring Boot!";  
    }  
  
}

Prueba de la aplicación

Para probar la aplicación y ver el HelloWorld bastaría con ejecutar en nuestro IDE la clase anotada con SpringBootApplication.

En la consola veremos aparecer varios logs que nos indicarán:

• Inicialización del servidor web (Tomcat por defecto) y el puerto en el que estará escuchando para recibir las peticiones (8080 por defecto)
• Inicialización correcta de la propia aplicación.

En ese momento, podremos abrir un navegador web e intentar cargar la url http://localhost:8080/hello lo cual realiza por defecto una petición GET a la ruta, devolviendo en la pantalla el texto de HelloWorld.

Conclusiones

Montar un Hello World en Spring Boot es rápido y sencillo, y un buen punto de partida para entender las piezas que lo hacen posible. Las anotaciones son uno de los pilares del framework, y dominar su significado permite construir aplicaciones más limpias, expresivas y mantenibles.