Alkroĉi prokuran transportfabrikon al la REST-kliento de BigQuery Java
Uzu HttpTransportOptions sur la ekzistanta agordo de projekto kaj akreditaĵoj, kun aparta transport-agordo se la akreditaĵoj mem faras ĵetonpetojn.
import java.net.InetSocketAddress;
import java.net.Proxy;
import com.google.api.client.http.javanet.NetHttpTransport;
import com.google.cloud.http.HttpTransportOptions;
import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryOptions;
var proxy = new Proxy(Proxy.Type.HTTP,
new InetSocketAddress("proxy.example", 8080));
var httpOptions = HttpTransportOptions.newBuilder()
.setHttpTransportFactory(() ->
new NetHttpTransport.Builder().setProxy(proxy).build())
.build();
BigQuery bigQuery = BigQueryOptions.newBuilder()
.setProjectId(projectId)
.setCredentials(credentials)
.setTransportOptions(httpOptions)
.build()
.getService();Uzu ĉi tiun bigQuery-kazon por la REST-operacioj. projectId kaj credentials venas el la ekzistanta agordo de la aplikaĵo.
La fabriko kreas la HTTP-transporton, kiu atingas la BigQuery-API tra la peranto. La API-finpunkto restas la celo; anstataŭigi ĝin per la prokura adreso petas alian servon. Por permesita publika prokura vojo al BigQuery, la listo de HTTP-prokuradoj liveras kandidatojn por la kampoj InetSocketAddress.
Akiro aŭ refreŝigo de akreditaĵoj povas havi propran HTTP-transporton, do agordu tiun subtenatan enigon kiam ĝiaj petoj bezonas la prokuron. Ĉi tiuj REST-opcioj ankaŭ ne agordas sendependan gRPC-kanalon.
Por sistema malkovro, java.net.useSystemProxies havas platform-specifan konduton kaj ne garantias, ke valoro Docker HTTP_PROXY fariĝos la vojo de ĉi tiu kliento. La eksplicita fabriko supre igas la elektitan REST-transporton videbla ĉe konstruado.