Поставете ја мрежната рута на 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 и довербата во сертификатот се одделни барања; само рута не обезбедува сите шеми за автентикација.

Поврзани статии