Некаторыя выклікі павінны ісці праз карпаратыўны проксі, а іншая служба дасягаецца напрамую. Дайце гэтым маршрутам асобныя экзэмпляры 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, абмяжуйце гэтага пастаўшчыка канчатковым пунктам проксі.

Іншыя перахопнікі або фабрыкі запытаў, наўмысна ўсталяваныя праграмай, усё яшчэ належаць да ўласнай канфігурацыі кліента. Трымайце іх з маршрутам, якому яны сапраўды патрэбныя.

Падобныя артыкулы