Por qué usar HttpClient para conexión síncrona

Estoy construyendo una biblioteca de clases para interactuar con una API. Necesito llamar a la API y procesar la respuesta XML. Puedo ver los beneficios de usar HttpClient para la conectividad asincrónica, pero lo que estoy haciendo es puramente sincrónico, por lo que no puedo ver ningún beneficio significativo sobre el uso de HttpWebRequest .

Si alguien puede arrojar alguna luz, lo agradecería mucho. No soy de los que usan nuevas tecnologías por el mero hecho de hacerlo.

pero lo que estoy haciendo es puramente sincrónico

Podría usar HttpClient para solicitudes sincrónicas muy bien:

 using (var client = new HttpClient()) { var response = client.GetAsync("http://google.com").Result; if (response.IsSuccessStatusCode) { var responseContent = response.Content; // by calling .Result you are synchronously reading the result string responseString = responseContent.ReadAsStringAsync().Result; Console.WriteLine(responseString); } } 

En cuanto a por qué debería usar HttpClient sobre WebRequest, bueno, HttpClient es el nuevo chico en el bloque y podría contener mejoras sobre el antiguo cliente.

Reiteré la respuesta de Donny V. y Josh

“La única razón por la que no usaría la versión asincrónica es si estuviera intentando admitir una versión anterior de .NET que aún no se haya incorporado en la compatibilidad asincrónica”.

(y upvote si tuviera la reputación)

No puedo recordar la última vez, si alguna vez, estaba agradecido por el hecho de que HttpWebRequest arrojó excepciones para códigos de estado> = 400. Para evitar estos problemas, debe detectar las excepciones de inmediato y asignarlas a algunos mecanismos de respuesta que no sean de excepción. en tu código … aburrido, tedioso y propenso a errores en sí mismo. Ya sea que se comunique con una base de datos o implemente un proxy web a medida, es “casi” siempre deseable que el controlador Http simplemente diga a su código de la aplicación qué fue lo que le devolvieron, y deje que usted decida cómo comportarse.

Por lo tanto HttpClient es preferible.

La razón principal por la que uso HttpClient es porque no arroja una excepción cuando se devuelve un 404 en una URL.

Si está creando una biblioteca de clases, quizás los usuarios de su biblioteca quieran usar su biblioteca de forma asincrónica. Creo que esa es la razón más importante allí.

Tampoco sabe cómo se usará su biblioteca. Tal vez los usuarios procesarán muchas y muchas solicitudes, y hacerlo de manera asincrónica lo ayudará a funcionar de manera más rápida y eficiente.

Si puede hacerlo de manera sencilla, trate de no imponerle una carga a los usuarios de su biblioteca que intentan hacer que el flujo sea asíncrono cuando puede ocuparse de ellos.

La única razón por la que no usaría la versión asíncrona es si estaba intentando admitir una versión anterior de .NET que aún no se haya incorporado en la compatibilidad asincrónica.

En mi caso, la respuesta aceptada no funcionó. Estaba llamando a la API desde una aplicación MVC que no tenía acciones asíncronas.

Así es como me las arreglé para hacer que funcione:

 private static readonly TaskFactory _myTaskFactory = new TaskFactory(CancellationToken.None, TaskCreationOptions.None, TaskContinuationOptions.None, TaskScheduler.Default); public static T RunSync(Func> func) { CultureInfo cultureUi = CultureInfo.CurrentUICulture; CultureInfo culture = CultureInfo.CurrentCulture; return _myTaskFactory.StartNew>(delegate { Thread.CurrentThread.CurrentCulture = culture; Thread.CurrentThread.CurrentUICulture = cultureUi; return func(); }).Unwrap().GetAwaiter().GetResult(); } 

Entonces lo llamé así:

 Helper.RunSync(new Func>(async () => await AsyncCallGoesHere(myparameter)));