Пишут ли вручную HTTP клиент с URL и параметрами для вызова сервиса

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

Как вы вызываете соседний сервис и что кладёте вокруг вызова. Ручная сборка URL сама по себе не грех, но обычно она признак того, что рядом нет ни таймаутов, ни разбора кодов ответа, ни метрик. Спрашивают про клиент, слушают про устойчивость.

Как отвечать

Скажите, чем пользуетесь и почему. В Spring Boot сейчас обычно декларативный клиент: интерфейс с @GetExchange поверх RestClient или WebClient, собранный через HttpServiceProxyFactory. В проектах со Spring Cloud живёт Feign. RestTemplate остаётся в поддержке, новые вызовы на нём не пишут. Если лишних зависимостей быть не должно, берут java.net.http.HttpClient из JDK, а не HttpURLConnection.

Дальше про обвязку, ради которой вопрос и задан:

• таймауты на соединение и на ответ обязательны, ожидание по умолчанию у многих клиентов бесконечно;
• повтор только для идемпотентных операций, с паузой и разбросом, иначе упавший сосед получит синхронный шторм;
• размыкатель и запасное поведение (Resilience4j);
• пул соединений переиспользуется, клиент создаётся один раз бином, а не на каждый вызов;
• параметры собираются билдером, а не конкатенацией.

URI uri = UriComponentsBuilder.fromUriString(baseUrl)
    .path("/orders")
    .queryParam("status", status)
    .encode()
    .build()
    .toUri();

Отдельно разделите обработку ответов: 4xx это наша ошибка и повторять её бессмысленно, 5xx и таймаут это кандидаты на повтор.

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

Клеят адрес строкой. Первое же значение с пробелом, плюсом или кириллицей ломает запрос, а если параметр пришёл от пользователя, вместе с ним уезжает и подстановка в путь.

Второе: забывают таймауты. Один медленный сосед выедает пул потоков, и сервис перестаёт отвечать целиком, хотя собственный код исправен. Это самая частая причина каскадного отказа.

Третье: включают повторы глобально. Создание заказа уходит дважды и порождает дубль, потому что потерялся ответ, а не запрос. Либо наоборот повторяют 400, который не станет успешным никогда.