Koppel 'n proxy-vervoerfabriek aan BigQuery Java se REST-kliënt

Gebruik HttpTransportOptions op die bestaande projek- en geloofsbriewekonfigurasie, met aparte vervoeropstelling as die geloofsbrief self tokenversoeke doen.

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

Gebruik hierdie bigQuery-instansie vir die REST-bewerkings. projectId en credentials kom uit die toepassing se bestaande konfigurasie.

Die fabriek skep die HTTP-vervoer wat die BigQuery-API deur die tussenganger bereik. Die API-eindpunt bly die bestemming; om dit met die proxy-adres te vervang, vra vir 'n ander diens. Vir 'n toegelate roete deur 'n publieke proxy na BigQuery lewer die HTTP-proxylys kandidate vir die InetSocketAddress-velde.

Die verkryging of vernuwing van geloofsbriewe kan sy eie HTTP-vervoer hê, so stel daardie ondersteunde invoer op wanneer sy versoeke die proxy nodig het. Hierdie REST-opsies stel ook nie 'n onafhanklike gRPC-kanaal op nie.

Vir stelselontdekking het java.net.useSystemProxies platformspesifieke gedrag en waarborg dit nie dat 'n Docker-waarde vir HTTP_PROXY hierdie kliënt se roete word nie. Die eksplisiete fabriek hierbo maak die gekose REST-vervoer sigbaar by konstruksie.

Verwante artikels