Hergebruik OkHttp-hulpbronne terwyl jy 'n ander proxy kies

'n OkHttp-versoek het nie 'n algemene veranderbare proxyveld nie. Kies die kliënt met die beoogde roete voordat jy sy oproep skep.

Wanneer die res van die konfigurasie gedeel moet bly, lei die gerouteerde kliënt van 'n bestaande kliënt af:

OkHttpClient routed = baseClient.newBuilder()
    .proxy(new Proxy(Proxy.Type.HTTP,
        new InetSocketAddress("203.0.113.10", 8080)))
    .build();

Die eindpunt is illustratief. Openbare HTTP-eindpunte uit die HTTP-proxylys kan hierdie sokadres vul vir 'n toegelate openbare-diensroete, mits die basiskliënt se beleid geen proxy-gewysigdes aan die nuwe eindpunt verskaf nie. OkHttp dokumenteer dat newBuilder konneksiepoel- en draadhulpbronne met die oorspronklike kliënt deel. Dit beteken nie dat 'n sok wat deur een proxy gevestig is, as 'n ander roete herbenoem kan word nie. Konneksiegeskiktheid hang steeds van die roete- en adreskonfigurasie af.

Vir herhaalde werk, hou 'n begrensde stel kliënte wat volgens die routeringsbeleid gesleutel is wat jy werklik nodig het. Vermy 'n onbegrensde kaart waarvan die sleutels elke tydelike rekening of proxy-variasie bevat wat ooit gesien is.

Hulpbronverdeling beïnvloed ook afsluiting. Om 'n gedeelde kas te sluit of 'n gedeelde versender af te skakel kan ander afgeleide kliënte wat daardie hulpbronne gebruik, raak. Gee hulpbron-eienaarskap 'n duidelike toepassingsvlak-leeftyd eerder as om elke afgeleide kliënt as 'n geïsoleerde netwerkstapel te behandel.

Laastens, sluit die gekose proxy-identiteit in die oproep se eie metadata in. 'n Globale veranderlike “laas gekose proxy” kan nie die roete van verskeie gelyktydige versoeke identifiseer nie.