Навіщо використовувати HttpClient для синхронного з'єднання

Я будую бібліотеку класів для взаємодії з API. Мені потрібно зателефонувати в API та обробити відповідь XML. Я бачу переваги використання HttpClientдля асинхронного підключення, але те, що я роблю, суто синхронне, тому я не бачу суттєвої користі від використання HttpWebRequest.

Якщо хтось може пролити будь-яке світло, я дуже вдячний. Я не один для того, щоб використовувати нову технологію заради неї.

але те, що я роблю, є чисто синхронним

Ви можете просто використовувати 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);
    }
}

Що стосується того, чому вам варто скористатися HttpClientнад WebRequest, то, чи HttpClientє новий хлопець у блоці і може містити покращення щодо старого клієнта.

Я б повторно повторив відповідь Донні В. та відповіді Джоша

"Єдина причина, по якій я не використовував би версію async, - це якщо я намагався підтримати старішу версію .NET, яка ще не має вбудованої підтримки async."

(і подати заяву, якщо я мав репутацію.)

Я не можу пригадати востаннє, якщо коли-небудь, я був вдячний факту, що HttpWebRequest викинув винятки для кодів статусу> = 400. Щоб обійти ці проблеми, потрібно негайно зловити винятки та віднести їх до деяких механізмів реагування на виключення у вашому коді ... нудно, нудно і схильність до помилок. Незалежно від того, чи це спілкування з базою даних, або реалізація веб-проксі-сервера на замовлення, майже "завжди" бажано, щоб драйвер Http просто повідомив вашому коду програми, що було повернуто, і вирішити, як вести себе.

Отже HttpClient є кращим.

Якщо ви будуєте бібліотеку класів, можливо, користувачі вашої бібліотеки хотіли б використовувати вашу бібліотеку асинхронно. Я думаю, що це найбільша причина саме там.

Ви також не знаєте, як використовуватиметься ваша бібліотека. Можливо, користувачі будуть обробляти багато і багато запитів, і це робити асинхронно допоможе виконувати її швидше та ефективніше.

Якщо ви можете це зробити просто, намагайтеся не покладати на себе тягар на користувачів вашої бібліотеки, намагаючись зробити потік асинхронним, коли ви можете піклуватися про них за них.

Єдина причина, по якій я не використовував би версію async - це якщо я намагався підтримати старішу версію .NET, яка ще не має вбудованої підтримки async.

У моєму випадку прийнята відповідь не спрацювала. Я дзвонив API з програми MVC, яка не мала жодних асинхронних дій.

Ось як мені вдалося змусити його працювати:

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

Тоді я назвав це так:

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

Тоді

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

якщо ви використовуєте цей клас, передайте метод асинхронізації як параметр, ви можете викликати методи асинхронізації з методів синхронізації безпечним способом.

це пояснено тут: https://cpratt.co/async-tips-tricks/

Здається, всі відповіді зосереджені на використанні HttpClientсинхронно, а не на фактичній відповіді на питання.

HttpClientє більш ніж простим обробником запитів / відповідей, тому він може мати справу з деякими особливостями різних мереж. А саме в моєму випадку працюю з проксі-сервером NTLM, який вимагає узгодження, надсилання декількох запитів / відповідей з маркерами та обліковими записами між клієнтом та проксі-сервером для аутентифікації.HttpClient(за допомогою HttpClientHandler), здається, є вбудований механізм, який обробляє, що повертає ресурси за межами проксі за допомогою одного виклику методу.