Réutiliser les ressources d'OkHttp en choisissant un autre proxy

Une requête OkHttp n'a pas de champ proxy modifiable général. Choisissez le client ayant la route voulue avant de créer son appel.

Lorsque le reste de la configuration doit rester partagé, dérivez le client routé à partir d'un client existant :

OkHttpClient routed = baseClient.newBuilder()
    .proxy(new Proxy(Proxy.Type.HTTP,
        new InetSocketAddress("203.0.113.10", 8080)))
    .build();

Le point de terminaison est illustratif. Les points de terminaison HTTP publics de la liste de proxys HTTP peuvent renseigner cette adresse de socket pour une route de service public autorisée, à condition que la politique du client de base ne fournisse aucun identifiant de proxy au nouveau point de terminaison. OkHttp documente que newBuilder partage les ressources du pool de connexions et des threads avec le client d'origine. Cela ne signifie pas qu'un socket établi via un proxy puisse être réétiqueté comme une autre route. L'éligibilité de la connexion dépend toujours de la configuration de la route et de l'adresse.

Pour un travail répété, conservez un ensemble borné de clients indexés par la politique de routage dont vous avez réellement besoin. Évitez une table non bornée dont les clés contiendraient chaque compte temporaire ou variation de proxy jamais observés.

Le partage des ressources influe aussi sur l'arrêt. Fermer un cache partagé ou arrêter un répartiteur partagé peut affecter d'autres clients dérivés qui utilisent ces ressources. Donnez à la propriété des ressources une durée de vie claire au niveau applicatif plutôt que de traiter chaque client dérivé comme une pile réseau isolée.

Enfin, incluez l'identité du proxy sélectionné dans les métadonnées propres à l'appel. Une variable globale « dernier proxy choisi » ne peut pas identifier la route de plusieurs requêtes simultanées.