RESTEasy 6.2: הגדרת פרוקסי קדמי בבונה הלקוח

הגדירו את מסלול הרשת בלקוח RESTEasy לפני יצירת אובייקט ה-API המסומן. פרוקסי API טיפוסי הוא אובייקט Java, לא המתווך ברשת הקדמי.

import jakarta.ws.rs.client.ClientBuilder;
import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder;

ResteasyClientBuilder builder =
    (ResteasyClientBuilder) ClientBuilder.newBuilder();

ResteasyClient client = builder
    .defaultProxy("proxy.example.net", 8080, "http")
    .build();

MyApi api = client
    .target("https://api.example.net")
    .proxy(MyApi.class);

זוהי ה-API של Jakarta ב-RESTEasy 6.2, כאשר RESTEasy הוא ספק הלקוח המותקן ו-MyApi כבר מוגדר על ידי היישום. ארגומנטי הפרוקסי הם שם מארח, פורט שלם וסכימת תעבורה של הפרוקסי. לבקשות מורשות ל-API ציבוריים, השתמשו בנקודת קצה HTTP מתאימה מהשירות שלכם או ברשימת פרוקסי HTTP. השאירו את יעד ה-API על target; API ב-HTTPS יכול להשתמש בפרוקסי HTTP.

השאירו את הלקוח פעיל לקריאות של הפרוקסי הטיפוסי שלו, ואז סגרו אותו בסיום העבודה. החזרת אובייקט ה-API מהיקף לקוח שכבר נסגר משאירה אותו בלי התעבורה שלו.

החליטו למי שייכת התעבורה הזו. תיעוד הבונה מתאר את שילוב Apache HTTP Client כברירת מחדל. ClientHttpEngine שסופק משנה את הגבול: httpEngine מחליף את הגדרות ה-SSL וההגדרות הספציפיות לחיבור של הבונה. הגדירו פרוקסי ו-TLS דרך הממשק הנתמך של אותו מנוע.

דוגמאות ישנות יותר המבוססות על ClientExecutor מגדירות במקום זאת לקוח Apache עטוף. התאימו לדור הזה במקום להדביק אותו בבונה Jakarta.

בשני הענפים, שמרו על שם המארח של ה-API כזהות TLS עם אימות מופעל. אימות פרוקסי, התחברות ל-API ואמון בתעודה הם דרישות נפרדות; מסלול לבדו אינו מספק כל סכימת אימות.