חיבור מפעל תעבורת פרוקסי ללקוח ה-REST של BigQuery Java

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

השתמשו במופע bigQuery הזה לפעולות ה-REST. projectId ו-credentials מגיעים מהתצורה הקיימת של היישום.

המפעל יוצר את תעבורת ה-HTTP שמגיעה אל ה-API של BigQuery דרך המתווך. נקודת הקצה של ה-API נשארת היעד; החלפתה בכתובת הפרוקסי מבקשת שירות אחר. עבור מסלול פרוקסי ציבורי מורשה אל BigQuery, רשימת פרוקסי ה-HTTP מספקת מועמדים לשדות InetSocketAddress.

להשגה או לחידוש של הרשאות יכולה להיות תעבורת HTTP משל עצמה, לכן הגדירו את הקלט הנתמך הזה כשהבקשות שלו זקוקות לפרוקסי. אפשרויות ה-REST האלה גם אינן מגדירות ערוץ gRPC עצמאי.

לגילוי מערכת, ל-java.net.useSystemProxies יש התנהגות תלוית פלטפורמה והוא אינו מבטיח שערך Docker HTTP_PROXY יהפוך למסלול של לקוח זה. המפעל המפורש שלמעלה הופך את תעבורת ה-REST שנבחרה לגלויה כבר בעת הבנייה.