Por que usar o HttpClient para conexão síncrona

Eu estou construindo uma biblioteca de classs para interagir com uma API. Eu preciso chamar a API e processar a resposta XML. Eu posso ver os benefícios de usar o HttpClient para conectividade assíncrona, mas o que estou fazendo é puramente síncrono, então não vejo nenhum benefício significativo sobre o uso do HttpWebRequest .

Se alguém puder derramar alguma luz, agradeceria muito. Eu não sou um para usar novas tecnologias por causa disso.

mas o que estou fazendo é puramente sincrônico

Você poderia usar o HttpClient para solicitações síncronas bem:

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

Quanto ao motivo pelo qual você deve usar o HttpClient em vez do WebRequest, o HttpClient é o novo garoto no bloco e pode conter melhorias em relação ao cliente antigo.

Eu reiteraria Donny V. responder e Josh

“A única razão pela qual eu não usaria a versão assíncrona é se eu estivesse tentando suportar uma versão mais antiga do .NET que ainda não tenha construído suporte asynchronous.”

(e upvote se eu tivesse a reputação.)

Não me lembro da última vez, se alguma vez, fiquei grato pelo fato de o HttpWebRequest ter lançado exceções para códigos de status> = 400. Para contornar esses problemas, você precisa capturar as exceções imediatamente e mapeá-las para alguns mecanismos de resposta que não são de exceção. no seu código … chato, tedioso e propenso a erros em si mesmo. Seja comunicando-se com um database ou implementando um proxy da Web sob medida, é quase sempre desejável que o driver Http informe ao código do aplicativo o que foi retornado e deixe que você decida como se comportar.

Por isso, o HttpClient é preferível.

A principal razão pela qual eu uso o HttpClient é porque ele não lança uma exceção quando um 404 é retornado em uma URL.

Se você estiver criando uma biblioteca de classs, talvez os usuários da sua biblioteca desejem usar sua biblioteca de forma assíncrona. Eu acho que essa é a maior razão aí mesmo.

Você também não sabe como sua biblioteca será usada. Talvez os usuários processem muitos e muitos pedidos e, de forma assíncrona, isso o ajude a executar de maneira mais rápida e eficiente.

Se você puder fazer isso simplesmente, tente não sobrecarregar os usuários da sua biblioteca tentando tornar o stream asynchronous quando você puder cuidar deles.

A única razão pela qual eu não usaria a versão assíncrona é se eu estivesse tentando suportar uma versão mais antiga do .NET que ainda não tenha construído suporte asynchronous.

No meu caso, a resposta aceita não funcionou. Eu estava chamando a API de um aplicativo MVC que não tinha ações assíncronas.

Foi assim que consegui fazer funcionar:

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

Então eu chamei assim:

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