Деякі виклики мають іти через корпоративний проксі, тоді як інший сервіс доступний безпосередньо. Дайте цим маршрутам окремі екземпляри RestTemplate замість зміни однієї спільної фабрики, поки запити можуть перекриватися.

Усередині наявного класу конфігурації Spring:

@Bean("directRestTemplate")
RestTemplate directRestTemplate() {
    var factory = new SimpleClientHttpRequestFactory();
    factory.setProxy(java.net.Proxy.NO_PROXY);
    return new RestTemplate(factory);
}

@Bean("proxyRestTemplate")
RestTemplate proxyRestTemplate() {
    var factory = new SimpleClientHttpRequestFactory();
    factory.setProxy(new java.net.Proxy(
        java.net.Proxy.Type.HTTP,
        new java.net.InetSocketAddress("proxy.example", 8080)));
    return new RestTemplate(factory);
}

Для фабрики запитів JDK у Spring 6.2 Proxy.NO_PROXY задає явну політику прямого з'єднання. Якщо залишити проксі фабрики незаданим, натомість дозволяється звичайний шлях конфігурації URLConnection, який може вибрати проксі JVM.

Використовуйте @Qualifier у точці ін'єкції, щоб вибрати потрібний бін, наприклад @Qualifier("directRestTemplate") RestTemplate rest. Сам лише опис двох бінів не вибирає між ними для неоднозначної залежності.

Цей приклад вибирає HTTP-проксі без автентифікації. Транспорт, якому потрібна автентифікація проксі, можна зібрати окремо з його підтримуваним постачальником облікових даних, зберігши ту саму схему вибору бінів. Для Spring 6 з Apache HttpClient 5 обмежте цього постачальника кінцевою точкою проксі.

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

Схожі статті