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.

El consumo de una API REST es un caso muy habitual cuando trabajamos en una arquitectura de microservicios, y es casi que la opción por defecto para el tráfico entre los distintos microservicios (aunque si es por eficiencia, deberíamos usarlo solo para tráfico norte-sur y optar por otras opciones más eficientes como gRPC para el tráfico este-oeste). Normalmente, en el mundo de Spring usamos por defecto dos opciones: Si estamos usando el stack bloqueante (web) RestTemplate. Si usamos el stack reactivo (webflux) WebClient. Los años de RestTemplate (13) se notan si hemos usado WebClient, ya que tiene una API mucho más concisa y fluida, más elegante. La contraprestación es que está diseñado para trabajar con Spring WebFlux y por tanto usa los tipos de datos reactivos Flux y Mono, por lo que si tu aplicación sigue un modelo bloqueante, vas a trufar todos los usos de WebClient con bloqueos para obtener los resultados y conversiones de Mono a tipos concretos o de Flux a colecciones.

En 2016 decidí pasar este blog de un WordPress (que me costaba un dinero anual en hosting) a un sitio estático (aunque con comentarios de Disqus). En ese momento estuve muy influenciado por la web de Trisha que usaba esta arquitectura pero usando todo el potencial de GitHub Pages, con Jekyll y la construcción automática del sitio al subir los archivos markdown a GitHub (curiosamente ella ahora usa WordPress, pero claro tiene infinito más contenido que yo y de más calidad, jaja).

Últimamente he tenido que provisionar dos equipos nuevos (en casa y en el trabajo) y parte del proceso es instalar Git para acceder a los distintos repositorios (como el de este blog). El acceso a un repositorio remoto de Git se puede hacer de dos maneras: Por cruce de clave SSH: De lejos el más cómodo y mejor una vez configurado. Generas un clave en tu equipo, subes la parte pública a GitHub, GitLab, etc… y a volar. El problema es que es harto tedioso. Mediante HTTPS: Cada vez que operemos sobre el repositorio remoto será como acceder a una página web y nos pedirá usuario y contraseña (credenciales). Este sistema es el más sencillo, pero dado el número de operaciones que puedes hacer en un rato sobre un remoto resulta muy tedioso estar introduciendo usuario y contraseña continuamente. Ahí entra el concepto de [Credential Helper] (https://git-scm.com/docs/gitcredentials), habiendo a su vez varias opciones: