Задайте сетевой маршрут в клиенте RESTEasy до создания аннотированного объекта API. Типизированный прокси API — это объект Java, а не промежуточный сетевой посредник.

import jakarta.ws.rs.client.ClientBuilder;
import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder;

ResteasyClientBuilder builder =
    (ResteasyClientBuilder) ClientBuilder.newBuilder();

ResteasyClient client = builder
    .defaultProxy("proxy.example.net", 8080, "http")
    .build();

MyApi api = client
    .target("https://api.example.net")
    .proxy(MyApi.class);

Это Jakarta API RESTEasy 6.2, где RESTEasy — установленный поставщик клиента, а MyApi уже определён приложением. Аргументы прокси — имя хоста, целочисленный порт и схема транспорта прокси. Для разрешённых запросов к публичным API используйте подходящую HTTP-конечную точку из вашего сервиса или список HTTP-прокси. Оставьте назначение API на target; API по HTTPS может использовать HTTP-прокси.

Держите клиент живым для вызовов его типизированного прокси, а затем закрывайте его по завершении работы. Возврат объекта API из уже закрытой области клиента оставляет его без транспорта.

Решите, кому принадлежит этот транспорт. Документация конструктора описывает стандартную интеграцию Apache HTTP Client. Переданный ClientHttpEngine меняет границу: httpEngine заменяет SSL и конфигурацию, специфичную для соединения, у конструктора. Настройте прокси и TLS через поддерживаемый интерфейс этого движка.

Более старые примеры на основе ClientExecutor вместо этого настраивают обёрнутый клиент Apache. Соответствуйте тому поколению, а не вставляйте его в конструктор Jakarta.

В обеих ветвях сохраняйте имя хоста API как идентичность TLS с включённой проверкой. Аутентификация прокси, вход в API и доверие к сертификату — это отдельные требования; один маршрут не обеспечивает все схемы аутентификации.

Похожие статьи