Imagen de Tara Winstead en Pexels
HttpClient y IHttpClientFactory se usan en .NET para realizar solicitudes/respuestas HTTP. Si llevas mucho tiempo con .NET y conoces las diferencias, poco o nada te aportará este artículo, aunque quizá te sorprenda y algo nuevo pueda aportarte. Si no lo sabes o tienes curiosidad, te animo a leerlo. No obstante, cuando realizo review de código aún me encuentro con un uso indebido de HttpClient (por ejemplo) y siempre termino copiando y pegando los mismos artículos para que se coja contexto y puedan mejorar su código cualquier dev.
¿Por qué lees otra vez sobre lo mismo?
Lo primero es saber que HttpClient está con nosotros desde la versión 4.5 del Framework, es decir, desde 2012 y se mantiene en las siguientes versiones. Sin embargo, IHttpClientFactory se introduce en .Net Core 2.1.
Siendo HttpClient algo que lleva con nosotros 10 años, aun veo en código nuevo, no legacy, nuevo, unsando mal el HttpClient.
Por ejemplo, en este artículo: You’re using HttpClient wrong and It is destabilizing your software, o bien usandolo en la DI sin que sea singleton o static en un método.
El artículo explica un problema muy común: Error SocketException. Este error ocurre cuando HttpClient deja la conexión abierta de TCP incluso después de que el objeto realice el dispose. La recomendación es que sea static/singleton que tienen sus propios overheads mientras se conecta a múltiples servicios.
Como veis el tema es algo que se lleva tratando mucho tiempo: leer más sobre el problema.
¿Qué me puede ayudar a realizar un mejor uso de HttpClient e IHttpClientFactory?
Como no os quiero hacer un refrito o un Copy&Paste de otros blogs, artículos de Microsoft, etc. Os voy a poner una serie de artículo que deberías leer para que te quede lo más claro posible y tengas las mismas fuentes que yo he usado, aunque luego habrá gente que te diga que todo es discutible, esto no, solo tienes que probar el ejemplo del artículo anterior y ver que no existe discusión alguna:
- Uso de IHttpClientFactory para implementar solicitudes HTTP resistentes. En este enlace tienes un libro para descargar: «.NET Microservices: Architecture for Containerized .NET Application».
- Directrices para usar HttpClient.
Parece que ya tienes claro cómo usar ambos, pero:
Por desgracia HttpClient presenta un nuevo problema en torno al DNS.
Cuando se necesita una nueva conexión HttpClient, primero verifica el registro DNS de un host para encontrar la dirección IP y luego realiza la conexión. Una vez la conexión establecida ya no mira en una segunda llamada si la IP pertenece a ese DNS.
Como recomendamos usar singleton esto puede ser un problema, no se detectan los cambios, por ejemplo, si tienes un Load Balacing para equilibrar cargas. El registro de DNS de un servicio al que esta llamando el HttpClient cambia durante la vida útil de la aplicación, un HttpClient singleton segirá llamando al servicio anterior.
Por tanto tenemos dos problemas con el HttpClient si no se tiene cuidado o se desconoce esto:
- Socket exhaustion.
- Rotación de DNS.
Y ¿quién soluciona esto? IHttpClientFactory, pero no usemos la regla del martillo de oro.
Te vendrá bien saber que es posible que en alguna circunstancia que no puedas usar IHttpClientFactory que a priori es la solución y debido a que no tienes DI los SocketHttpHandler serán nuestros aliados segun nos cuenta esta artículo: HttpClient connection pooling in .NET Core, es tu solución.
Conclusión:
Aunque estas cosas pueden parecer triviales a veces cuando llegan a producción detectar donde está el problema es complicado y más aún si no conoces estos dos posibles problemas.
Espero que estos pequeños detalles te puedan ayudar y como ves con 0 líneas de código. El código como ya os decía y los ejemplos, están mejor explicados en los enlaces que acompañan el artículo.
