RESTEasy 6.2: Einen Forward-Proxy im Client-Builder setzen
Konfigurieren Sie den HTTP-Transport von RESTEasy, bevor der typisierte API-Proxy erstellt wird, und berücksichtigen Sie die verwendete HTTP-Engine.
Legen Sie die Netzwerkroute im RESTEasy-Client fest, bevor das annotierte API-Objekt erzeugt wird. Ein typisierter API-Proxy ist ein Java-Objekt, nicht der vorgeschaltete Netzwerkvermittler.
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);Dies ist die Jakarta-API von RESTEasy 6.2, wobei RESTEasy als installierter Client-Provider dient und MyApi von der Anwendung bereits definiert ist. Die Proxy-Argumente sind Hostname, ganzzahliger Port und Transport-Schema des Proxys. Für erlaubte Anfragen an öffentliche APIs verwenden Sie einen passenden HTTP-Endpunkt aus Ihrem Dienst oder die HTTP-Proxy-Liste. Belassen Sie das Ziel der API auf target; eine HTTPS-API kann einen HTTP-Proxy nutzen.
Halten Sie den Client für die Aufrufe seines typisierten Proxys am Leben und schließen Sie ihn nach Abschluss der Arbeit. Wird das API-Objekt aus einem bereits geschlossenen Client-Bereich zurückgegeben, hat es keinen Transport mehr.
Entscheiden Sie, wem dieser Transport gehört. Die Builder-Dokumentation beschreibt die standardmäßige Integration des Apache HTTP Client. Ein übergebener ClientHttpEngine verschiebt die Grenze: httpEngine ersetzt die SSL- und verbindungsspezifische Konfiguration des Builders. Legen Sie Proxy und TLS über die unterstützte Schnittstelle dieser Engine fest.
Ältere Beispiele auf Basis von ClientExecutor konfigurieren stattdessen einen umhüllten Apache-Client. Bleiben Sie bei dieser Generation, statt sie in den Jakarta-Builder einzufügen.
Halten Sie in beiden Varianten den API-Hostnamen als TLS-Identität, mit aktivierter Verifikation. Proxy-Authentifizierung, API-Anmeldung und Zertifikatsvertrauen sind getrennte Anforderungen; eine Route allein deckt nicht jedes Authentifizierungsschema ab.