Perché usare HttpClient per la connessione sincrona

Sto costruendo una libreria di classi per interagire con un'API. Devo chiamare l'API ed elaborare la risposta XML. Posso vedere i vantaggi dell'utilizzo HttpClientdella connettività asincrona, ma quello che sto facendo è puramente sincrono, quindi non vedo alcun vantaggio significativo sull'uso HttpWebRequest.

Se qualcuno potesse far luce, lo apprezzerei molto. Non sono uno che usa la nuova tecnologia per il gusto di farlo.

ma quello che sto facendo è puramente sincrono

È possibile utilizzare HttpClientper le richieste sincrone bene:

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);
    }
}

Per quanto riguarda il motivo per cui dovresti usare HttpClientover WebRequest, beh, HttpClientè il nuovo bambino sul blocco e potrebbe contenere miglioramenti rispetto al vecchio client.

Reitererei la risposta di Donny V. e quella di Josh

"L'unico motivo per cui non utilizzerei la versione asincrona è se stessi cercando di supportare una versione precedente di .NET che non ha già integrato il supporto asincrono."

(e voto positivo se avessi la reputazione.)

Non riesco a ricordare l'ultima volta, se mai, ero grato del fatto che HttpWebRequest abbia generato eccezioni per codici di stato> = 400. Per aggirare questi problemi è necessario rilevare immediatamente le eccezioni e mapparle su alcuni meccanismi di risposta senza eccezioni nel tuo codice ... noioso, noioso e soggetto a errori in sé. Che si tratti di comunicare con un database o di implementare un proxy Web su misura, è 'quasi' sempre auspicabile che il driver Http dica semplicemente al codice dell'applicazione cosa è stato restituito e lascia a te decidere come comportarsi.

Quindi è preferibile HttpClient.

Se stai costruendo una libreria di classi, forse gli utenti della tua libreria vorrebbero utilizzare la tua libreria in modo asincrono. Penso che sia il motivo principale proprio lì.

Inoltre, non sai come verrà utilizzata la tua libreria. Forse gli utenti elaboreranno molte e molte richieste, e farlo in modo asincrono lo aiuterà a ottenere prestazioni più veloci ed efficienti.

Se riesci a farlo semplicemente, cerca di non gravare sugli utenti della tua libreria cercando di rendere il flusso asincrono quando puoi occupartene.

L'unico motivo per cui non utilizzerei la versione asincrona è se stessi cercando di supportare una versione precedente di .NET che non ha già integrato il supporto asincrono.

Nel mio caso la risposta accettata non ha funzionato. Stavo chiamando l'API da un'applicazione MVC che non aveva azioni asincrone.

Ecco come sono riuscito a farlo funzionare:

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();
    }

Quindi l'ho chiamato così:

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();
}

Poi

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

se usi quella classe passa il tuo metodo asincrono come parametro puoi chiamare i metodi asincroni dai metodi di sincronizzazione in modo sicuro.

è spiegato qui: https://cpratt.co/async-tips-tricks/

Tutte le risposte sembrano concentrarsi sull'uso HttpClientsincrono invece di dare una risposta effettiva alla domanda.

HttpClientè più di un semplice gestore di richieste / risposte, quindi può gestire alcune peculiarità di reti diverse. Vale a dire nel mio caso lavorare con il proxy NTLM che richiede negoziazione, invio di più richieste / risposte con token e credenziali tra client e server proxy per l'autenticazione. HttpClient(using HttpClientHandler) sembra avere un meccanismo incorporato che gestisce che restituisce risorse oltre il proxy con una chiamata di metodo.