Pourquoi utiliser HttpClient pour une connexion synchrone

Je construis une bibliothèque de classes pour interagir avec une API. Je dois appeler l'API et traiter la réponse XML. Je peux voir les avantages de l'utilisation HttpClientde la connectivité asynchrone, mais ce que je fais est purement synchrone, donc je ne vois aucun avantage significatif par rapport à l'utilisation HttpWebRequest.

Si quelqu'un peut faire la lumière, je l'apprécierais beaucoup. Je ne suis pas du genre à utiliser les nouvelles technologies pour le plaisir.

mais ce que je fais est purement synchrone

Vous pouvez très bien utiliser HttpClientpour les requêtes synchrones:

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 ce qui concerne la raison pour laquelle vous devriez utiliser HttpClientover WebRequest, eh bien, HttpClientle nouvel enfant est sur le point et pourrait contenir des améliorations par rapport à l'ancien client.

Je réitérerais la réponse de Donny V. et celle de Josh

"La seule raison pour laquelle je n'utiliserais pas la version asynchrone est si j'essayais de prendre en charge une version plus ancienne de .NET qui n'a pas déjà intégré la prise en charge asynchrone."

(et voter pour si j'avais la réputation.)

Je ne me souviens pas de la dernière fois, si jamais, j'étais reconnaissant du fait que HttpWebRequest ait lancé des exceptions pour les codes d'état> = 400. Pour contourner ces problèmes, vous devez attraper les exceptions immédiatement et les mapper à certains mécanismes de réponse sans exception dans votre code ... ennuyeux, fastidieux et sujet aux erreurs en soi. Qu'il s'agisse de communiquer avec une base de données ou d'implémenter un proxy Web sur mesure, il est «presque» toujours souhaitable que le pilote Http dise simplement à votre code d'application ce qui a été renvoyé et vous laisse le soin de décider comment vous comporter.

Par conséquent, HttpClient est préférable.

Si vous créez une bibliothèque de classes, les utilisateurs de votre bibliothèque souhaiteraient peut-être utiliser votre bibliothèque de manière asynchrone. Je pense que c'est la principale raison ici.

Vous ne savez pas non plus comment votre bibliothèque sera utilisée. Peut-être que les utilisateurs traiteront beaucoup, beaucoup de demandes, et le faire de manière asynchrone l'aidera à fonctionner plus rapidement et plus efficacement.

Si vous pouvez le faire simplement, essayez de ne pas mettre le fardeau sur les utilisateurs de votre bibliothèque qui tentent de rendre le flux asynchrone lorsque vous pouvez vous en occuper pour eux.

La seule raison pour laquelle je n'utiliserais pas la version asynchrone est si j'essayais de prendre en charge une ancienne version de .NET qui n'a pas déjà intégré la prise en charge asynchrone.

Dans mon cas, la réponse acceptée n'a pas fonctionné. J'appelais l'API à partir d'une application MVC qui n'avait aucune action asynchrone.

Voici comment j'ai réussi à le faire fonctionner:

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

Ensuite, je l'ai appelé comme ceci:

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

ensuite

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

si vous utilisez cette classe, passez votre méthode async comme paramètre, vous pouvez appeler les méthodes async à partir des méthodes de synchronisation de manière sûre.

c'est expliqué ici: https://cpratt.co/async-tips-tricks/

Toutes les réponses semblent se concentrer sur l'utilisation HttpClientsynchrone au lieu de donner une réponse réelle à la question.

HttpClientest plus qu'un simple gestionnaire de requêtes / réponses, il peut donc gérer certaines particularités de différents réseaux. À savoir dans mon cas, travailler avec un proxy NTLM qui nécessite une négociation, l'envoi de plusieurs demandes / réponses avec des jetons et des informations d'identification entre le client et le serveur proxy pour s'authentifier. HttpClient(using HttpClientHandler) semble avoir un mécanisme intégré qui gère le retour des ressources au-delà du proxy avec un seul appel de méthode.