Po co używać HttpClient do połączenia synchronicznego

Buduję bibliotekę klas do interakcji z interfejsem API. Muszę wywołać interfejs API i przetworzyć odpowiedź XML. Widzę zalety korzystania HttpClientz łączności asynchronicznej, ale to, co robię, jest czysto synchroniczne, więc nie widzę żadnej znaczącej korzyści z używania HttpWebRequest.

Jeśli ktoś mógłby rzucić jakiekolwiek światło, byłbym bardzo wdzięczny. Nie jestem zwolennikiem korzystania z nowych technologii ze względu na to.

ale to, co robię, jest czysto synchroniczne

Możesz użyć HttpClientdo synchronicznych żądań w porządku:

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

Jeśli chodzi dlaczego należy użyć HttpClientw ciągu WebRequestobawia się, dobrze, HttpClientjest New Kids on the Block i może zawierać ulepszenia w stosunku do starego klienta.

Powtórzę ponownie odpowiedź Donny V. i Josha

„Jedynym powodem, dla którego nie używałbym wersji asynchronicznej jest to, że próbuję obsługiwać starszą wersję platformy .NET, która nie ma jeszcze wbudowanej obsługi asynchronicznej.”

(i głosuj, gdybym miał reputację).

Nie pamiętam, kiedy ostatni raz, jeśli kiedykolwiek, byłem wdzięczny za to, że HttpWebRequest rzucił wyjątki dla kodów statusu> = 400. Aby obejść te problemy, musisz natychmiast wychwycić wyjątki i odwzorować je na niektóre mechanizmy odpowiedzi inne niż wyjątki w twoim kodzie ... sam w sobie nudny, nużący i podatny na błędy. Niezależnie od tego, czy komunikujesz się z bazą danych, czy wdrażasz specjalnie skonfigurowany serwer proxy sieci Web, „prawie” zawsze jest pożądane, aby sterownik Http po prostu powiedział kodowi aplikacji, co zostało zwrócone, i pozostawienie decyzji o tym, jak się zachować.

Dlatego preferowany jest HttpClient.

Jeśli budujesz bibliotekę klas, być może użytkownicy Twojej biblioteki chcieliby korzystać z niej asynchronicznie. Myślę, że to największy powód.

Nie wiesz także, w jaki sposób twoja biblioteka będzie używana. Być może użytkownicy będą przetwarzać wiele żądań, a robienie tego asynchronicznie pomoże mu działać szybciej i wydajniej.

Jeśli możesz to zrobić po prostu, staraj się nie obciążać użytkowników biblioteki, próbując uczynić przepływ asynchronicznym, kiedy możesz się nim zająć.

Jedynym powodem, dla którego nie używałbym wersji asynchronicznej jest to, że próbuję obsługiwać starszą wersję platformy .NET, która nie ma jeszcze wbudowanej obsługi asynchronicznej.

W moim przypadku zaakceptowana odpowiedź nie zadziałała. Dzwoniłem do API z aplikacji MVC, która nie miała akcji asynchronicznych.

Oto jak udało mi się sprawić, aby działało:

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

Potem nazwałem to tak:

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

Następnie

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

jeśli użyjesz tej klasy jako parametru, przekażesz metodę asynchroniczną, możesz wywoływać metody asynchroniczne z metod synchronizacji w bezpieczny sposób.

wyjaśniono to tutaj: https://cpratt.co/async-tips-tricks/

Wydaje się, że wszystkie odpowiedzi koncentrują się na użyciu HttpClientsynchronicznym zamiast na udzielaniu rzeczywistej odpowiedzi na pytanie.

HttpClientjest czymś więcej niż prostym modułem obsługi zapytań / odpowiedzi, więc może poradzić sobie z pewnymi osobliwościami różnych sieci. Mianowicie w moim przypadku praca z serwerem proxy NTLM, który wymaga negocjacji, wysyłanie wielu żądań / odpowiedzi z tokenami i poświadczeniami między klientem a serwerem proxy w celu uwierzytelnienia. HttpClient(using HttpClientHandler) wydaje się mieć wbudowany mechanizm, który obsługuje jedno kliknięcie metody, które zwraca zasoby poza proxy.