Perché utilizzare 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. Riesco a vedere i vantaggi dell’utilizzo di HttpClient per la connettività asincrona, ma quello che sto facendo è puramente sincrono, quindi non vedo alcun vantaggio significativo sull’utilizzo di HttpWebRequest .

Se qualcuno può far luce, lo apprezzerei molto. Non sono uno per l’utilizzo di nuove tecnologie per il gusto di farlo.

ma quello che sto facendo è puramente sincrono

È ansible utilizzare HttpClient per le richieste sincrone senza HttpClient :

 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 HttpClient su WebRequest, beh, HttpClient è il nuovo capretto sul blocco e potrebbe contenere miglioramenti rispetto al vecchio client.

Vorrei ripetere la risposta di Donny V. e Josh’s

“L’unica ragione per cui non utilizzerei la versione asincrona è se cercassi di supportare una versione precedente di .NET che non ha già il supporto asincrono incorporato.”

(e upvote se avessi la reputazione).

Non riesco a ricordare l’ultima volta, se mai, ero grato al fatto che HttpWebRequest ha lanciato eccezioni per i codici di stato> = 400. Per aggirare questi problemi è necessario rilevare immediatamente le eccezioni e mapparle su alcuni meccanismi di risposta non-eccezione nel tuo codice … noioso, noioso e sobject a errori di per sé. Che si tratti di comunicare con un database o di implementare un proxy web personalizzato, è quasi sempre auspicabile che il driver Http comunichi semplicemente al codice dell’applicazione quanto è stato restituito, e lascia decidere a te come comportarsi.

Quindi è preferibile HttpClient.

L’unico motivo principale per cui utilizzo HttpClient è perché non genera un’eccezione quando un 404 viene restituito su un URL.

Se stai creando una libreria di classi, allora forse gli utenti della tua libreria vorrebbero usare la tua libreria in modo asincrono. Penso che sia la più grande ragione proprio lì.

Inoltre non sai come verrà utilizzata la tua biblioteca. Forse gli utenti elaboreranno un sacco di richieste e, facendo ciò in modo asincrono, le renderanno più veloci ed efficienti.

Se puoi farlo semplicemente, cerca di non sovraccaricare gli utenti della tua libreria cercando di rendere il stream asincrono quando puoi occupartene per loro.

L’unica ragione per cui non utilizzerei la versione asincrona è se provassi a supportare una versione precedente di .NET che non ha già il supporto asincrono incorporato.

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

Allora l’ho chiamato così:

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