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.

Rilataj artikoloj