Был ли опыт использования HTTP клиента?

Что проверяют

За вопросом «был ли опыт» стоит проверка, знаете ли вы классические грабли HttpClient в .NET, а не только сам класс. Следом спросят, как вы управляли жизненным циклом клиента и что делали при таймаутах и ошибках.

Как отвечать

Стройте ответ на своей интеграции: какой внешний API, какой объём запросов, что пошло не так и как вы это решили. Цифры и детали нужны ваши, выдуманное «ускорили на 40%» интервьюер распознаёт за пару уточнений. Пункты, которые стоит затронуть:

• жизненный цикл: клиент создаётся через IHttpClientFactory, типизированный клиент регистрируется services.AddHttpClient<PaymentsClient>(). Без DI подходит один долгоживущий HttpClient с SocketsHttpHandler и заданным PooledConnectionLifetime, чтобы клиент замечал смену DNS;
• сериализация: GetFromJsonAsync и PostAsJsonAsync из System.Net.Http.Json поверх System.Text.Json вместо ручного ReadAsStringAsync и Newtonsoft;
• таймауты и отмена: HttpClient.Timeout по умолчанию 100 секунд, это почти всегда слишком много. Плюс CancellationToken, проброшенный из контроллера;
• устойчивость: повторы и circuit breaker через Microsoft.Extensions.Http.Resilience (AddStandardResilienceHandler) или Polly, причём повторяются только идемпотентные запросы;
• ошибки: разбор статус-кодов, а не голый EnsureSuccessStatusCode с проглатыванием исключения.

Если коммерческого опыта с внешними API не было, так и скажите и расскажите про пет-проект: какой API вызывали, как регистрировали клиент, как обработали бы сбои. Честное «делал на своём проекте, вот что понял» звучит сильнее выдуманной истории.

Где спотыкаются

Рассказывают про using var client = new HttpClient() на каждый запрос. Под нагрузкой это исчерпание сокетов, и следующим вопросом будет фабрика.

Ловят catch (Exception) и возвращают null. Вызывающий код не отличит «пользователь не найден» от упавшей сети.

Включают повторы для POST без ключа идемпотентности и получают дубли платежей или заказов.