Kople ein proxy-transportfabrikk til REST-klienten til BigQuery Java

Bruk HttpTransportOptions på den eksisterande prosjekt- og legitimasjonskonfigurasjonen, med eige transportoppsett dersom sjølve legitimasjonen sender tokenførespurnader.

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();

Bruk denne bigQuery-instansen for REST-operasjonane. projectId og credentials kjem frå den eksisterande konfigurasjonen til applikasjonen.

Fabrikken lagar HTTP-transporten som når BigQuery API gjennom mellomleddet. API-endepunktet blir verande destinasjonen; å byta det ut med proxyadressa ber om ei anna teneste. For ein tillaten offentleg proxy-rute til BigQuery leverer HTTP-proxylista kandidatar for InetSocketAddress-felta.

Innhenting eller fornying av legitimasjon kan ha sin eigen HTTP-transport, så konfigurer den støtta inndataen når førespurnadene treng proxyen. Desse REST-vala konfigurerer heller ikkje ein uavhengig gRPC-kanal.

For systemoppdaging har java.net.useSystemProxies plattformspesifikk åtferd og garanterer ikkje at ein Docker HTTP_PROXY-verdi blir ruta til denne klienten. Den eksplisitte fabrikken ovanfor gjer den valde REST-transporten synleg ved bygging.

Relaterte artiklar