La tentación de empezar a programar (y por qué deberías esperar) 🔗Como desarrolladores, nuestro primer impulso al empezar un proyecto es casi siempre el mismo: abrir el IDE y ponernos a picar código. 🚀 Ya sea eligiendo dependencias, escribiendo tests o definiendo el modelo de dominio, esa es la parte divertida, ¿verdad? Este enfoque funciona para pruebas de concepto rápidas. Pero si estás construyendo un producto a largo plazo, sobre todo en equipo, necesitas un plan. Hasta la idea más simple puede significar algo diferente para cada persona.

En artículos anteriores usábamos propiedades de configuración para pasar distintos parámetros a nuestra aplicación, haciendo algo de memoria, teníamos un secrets.properties en src/main/resources (junto con application.properties) con este contenido: song-server.base.url=http://localhost:3000 song-server.api-key=mytoken Y lo importábamos en application.properties: spring.config.import=secrets.properties spring.main.web-application-type=none logging.level.org.springframework.web=TRACE Eso nos permitía usar esas propiedades (las que empiezan por song-server) en nuestra aplicación, por ejemplo, a través de la anotación @value: @Bean public Map<String, String> headers(@Value("${song-server.api-key}") String apiKey) { return Map.of( HttpHeaders.CONTENT_TYPE, APPLICATION_JSON, HttpHeaders.AUTHORIZATION, "Bearer " + apiKey ); } Esto es muy cómodo y ya hemos visto que nos permite incluso sobreescribir el valor pasándolo como variable de entorno. Además, @Value nos permite especificar valores por defecto y otra serie de funciones avanzadas que son muy útiles.

Cuando trabajamos con recursos externos a nuestra aplicación (bases de datos, APIs con algún tipo de autenticación, etc…) es bastante habitual tener algún elemento como un nombre de usuario y contraseña o un token que no queremos publicar junto con el código de nuestra aplicación. Por ejemplo, en el artículo de Headers y HTTP Interface usábamos un API key en la cabecera para acceder al servidor. Esta API key en nuestro ejemplo esta en el application.properties:

Siguiendo con la serie de clientes REST con Spring, queda por cubrir un caso de uso muy frecuente, ¿cómo envío cabeceras? Si comparamos las dos soluciones que hemos visto hasta ahora, cuando usábamos RestClient, si que enviábamos la cabecera Accept al hacer peticiones GET y cuando hacíamos la petición POST, enviamos también la cabecera Content-Type. Sin embargo al usar HTTP Interface, no lo hemos utilizado y hemos confiado en que enviamos y recibimos siempre JSON. Eso incluso nos dá cierto problema que ya hemos visto al tratar los errores en el HTTP Interface, siendo necesario eliminar el contenido del buffer de entrada si recibimos una respuesta errónea (como un 404), ya que ahí estaríamos recibiendo texto en vez de JSON y falla el parseador de JSON.

Este artículo es una continuación del anterior, en el que usábamos RestClient para acceder a una API REST. Si no lo has leído, repásalo porque vamos a usar la misma API de reproducción de canciones para nuestro ejemplo. Como resumen rápido, en el artículo anterior teníamos esta API de canciones que hemos reproducido recientemente y usábamos el nuevo RestClient para acceder a ella y hacer algunas operaciones básicas, como traerlas todas, buscar una por su id o crear una nueva reproducción.