¿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 del uso HttpClientpara 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 HttpWebRequest.

Si alguien puede arrojar alguna luz, lo agradecería enormemente. No soy de los que usan las nuevas tecnologías por el bien de ellas.

pero lo que estoy haciendo es puramente sincrónico

Puede usar HttpClientpara solicitudes síncronas 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 HttpClientover, WebRequestse trata, bueno, HttpClientes el nuevo chico en el bloque y podría contener mejoras sobre el antiguo cliente.

Reiteraría la respuesta de Donny V. y la de Josh

"La única razón por la que no usaría la versión asincrónica es si intentara admitir una versión anterior de .NET que aún no tiene una compatibilidad asincrónica".

(Y votar si tuviera la reputación).

No recuerdo la última vez si alguna vez, agradecí el hecho de que HttpWebRequest arrojó excepciones para los códigos de estado> = 400. Para solucionar estos problemas, debe detectar las excepciones de inmediato y asignarlas a algunos mecanismos de respuesta que no sean excepciones. en su código ... aburrido, tedioso y propenso a errores en sí mismo. Ya sea que se comunique con una base de datos o que implemente un proxy web a medida, es 'casi' siempre deseable que el controlador Http solo le diga a su código de aplicación lo que se devolvió y le deje a usted decidir cómo comportarse.

Por lo tanto, HttpClient es preferible.

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

Tampoco sabes cómo se usará tu biblioteca. Quizás los usuarios procesarán muchas y muchas solicitudes, y hacerlo de forma asincrónica lo ayudará a funcionar de manera más rápida y eficiente.

Si puede hacerlo simplemente, trate de no cargar con la carga a los usuarios de su biblioteca que intentan hacer que el flujo sea asíncrono cuando pueda encargarse de ellos.

La única razón por la que no usaría la versión asincrónica es si intentara admitir una versión anterior de .NET que aún no tiene soporte asincrónico incorporado.

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 logré hacerlo funcionar:

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

Entonces lo llamé así:

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

public static class AsyncHelper  
{
    private static readonly TaskFactory _taskFactory = new
        TaskFactory(CancellationToken.None,
                    TaskCreationOptions.None,
                    TaskContinuationOptions.None,
                    TaskScheduler.Default);

    public static TResult RunSync<TResult>(Func<Task<TResult>> func)
        => _taskFactory
            .StartNew(func)
            .Unwrap()
            .GetAwaiter()
            .GetResult();

    public static void RunSync(Func<Task> func)
        => _taskFactory
            .StartNew(func)
            .Unwrap()
            .GetAwaiter()
            .GetResult();
}

Luego

AsyncHelper.RunSync(() => DoAsyncStuff());

si usa esa clase, pase su método asíncrono como parámetro, puede llamar a los métodos asíncronos desde los métodos de sincronización de manera segura.

se explica aquí: https://cpratt.co/async-tips-tricks/

Todas las respuestas parecen centrarse en el uso HttpClientsincrónico en lugar de dar una respuesta real a la pregunta.

HttpClientes más que un simple controlador de solicitud / respuesta, por lo que puede tratar algunas peculiaridades de diferentes redes. Es decir, en mi caso, trabajar con proxy NTLM que requiere negociación, enviando múltiples solicitudes / respuestas con tokens y credenciales entre el cliente y el servidor proxy para autenticar. HttpClient(usando HttpClientHandler) parece tener un mecanismo incorporado que maneja que devuelve recursos más allá del proxy con una llamada al método.