Задайте мережевий маршрут у клієнті 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; API через HTTPS може використовувати HTTP-проксі.

Тримайте клієнт живим для викликів його типізованого проксі, а потім закривайте його після завершення роботи. Повернення об'єкта API з уже закритої області клієнта залишає його без транспорту.

Вирішіть, кому належить цей транспорт. Документація конструктора описує стандартну інтеграцію Apache HTTP Client. Переданий ClientHttpEngine змінює межу: httpEngine замінює SSL і конфігурацію, специфічну для з'єднання, у конструкторі. Налаштуйте проксі та TLS через підтримуваний інтерфейс цього рушія.

Старіші приклади на основі ClientExecutor натомість налаштовують обгорнутий клієнт Apache. Відповідайте тому поколінню, а не вставляйте його в конструктор Jakarta.

В обох гілках зберігайте ім'я хоста API як ідентичність TLS з увімкненою перевіркою. Автентифікація проксі, вхід в API і довіра до сертифіката — окремі вимоги; один маршрут не забезпечує всі схеми автентифікації.

Схожі статті