Задайте мрежовия маршрут в клиента 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);

Това е Jakarta API на RESTEasy 6.2, като RESTEasy е инсталираният доставчик на клиента, а MyApi вече е дефиниран от приложението. Аргументите на проксито са име на хост, цяло число за порт и схема за транспорт на проксито. За разрешени заявки към публични API използвайте съответстваща HTTP крайна точка от вашата услуга или списъка с HTTP проксита. Оставете дестинацията на API на target; HTTPS API може да използва HTTP прокси.

Пазете клиента жив за извикванията на типизираното му прокси, след което го затворете при завършване на работата. Връщането на API обекта от вече затворен обхват на клиента го оставя без транспорт.

Решете кой притежава този транспорт. Документацията на конструктора описва стандартната интеграция с Apache HTTP Client. Предоставен ClientHttpEngine променя границата: httpEngine замества SSL и конфигурацията, специфична за връзката, на конструктора. Задайте прокси и TLS през поддържания интерфейс на този двигател.

По-стари примери, базирани на ClientExecutor, вместо това конфигурират обвит Apache клиент. Съобразете се с това поколение, вместо да го поставяте в конструктора на Jakarta.

И в двата случая пазете името на хоста на API като TLS идентичност с включена проверка. Удостоверяването на проксито, входът в API и доверието към сертификата са отделни изисквания; само маршрут не осигурява всички схеми за удостоверяване.

Подобни статии