

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Remplacer la configuration du client de service
<a name="override-client-config"></a>

Une fois qu'un [client de service est créé](creating-clients.md), celui-ci utilise une configuration fixe pour toutes les opérations. Cependant, il se peut que vous deviez parfois remplacer la configuration pour une ou plusieurs opérations spécifiques.

Chaque client de service possède une `withConfig` extension qui vous permet de modifier une copie de la configuration existante. L'`withConfig`extension renvoie un nouveau client de service avec une configuration modifiée. Le client d'origine existe indépendamment et utilise sa configuration d'origine.

L'exemple suivant montre la création d'une `S3Client` instance qui appelle deux opérations.

```
val s3 = S3Client.fromEnvironment {
    logMode = LogMode.LogRequest
    region = "us-west-2"
    // ...other configuration settings...
}

s3.listBuckets { ... }
s3.listObjectsV2 { ... }
```

L'extrait suivant montre comment remplacer la configuration pour une seule opération. `listObjectV2`

```
s3.withConfig {
    region = "eu-central-1"
}.use { overriddenS3 ->
    overriddenS3.listObjectsV2 { ... }
}
```

L'opération appelle le `s3` client à utiliser la configuration d'origine spécifiée lors de la création du client. Sa configuration inclut la [journalisation des demandes](logging.md#sdk-log-mode) et `us-west-2 region` pour la région. 

L'`listObjectsV2`invocation sur le `overriddenS3` client utilise les mêmes paramètres que le `s3` client d'origine, à l'exception de la région, qui est désormais `eu-central-1` utilisée.

## Cycle de vie d'un client remplacé
<a name="override-client-lifecycle"></a>

Dans l'exemple précédent, le `s3` client et le `overriddenS3` client sont indépendants l'un de l'autre. Les opérations peuvent être invoquées sur l'un ou l'autre client tant qu'elles restent ouvertes. Chacun utilise une configuration distincte, mais ils peuvent partager des ressources sous-jacentes (comme un moteur HTTP) à moins que celles-ci ne soient également remplacées. 

Vous fermez un client dont la configuration a été remplacée et le client d'origine séparément. Vous pouvez fermer un client dont la configuration a été modifiée avant ou après la fermeture de son client d'origine. À moins que vous n'ayez besoin d'utiliser un client dont la configuration a été remplacée pendant une longue période, nous vous recommandons de terminer son cycle de vie avec cette méthode. `use` La `use` méthode garantit que le client est fermé en cas d'exceptions. 

## Ressources partagées entre les clients
<a name="override-client-shared-res"></a>

Lorsque vous créez un client de service à l'aide de`withConfig`, il peut partager des ressources avec le client d'origine. En revanche, lorsque vous créez un client à l'aide de [FromEnvironment](creating-clients.md#loading-from-the-environment) ou que vous le [configurez explicitement, le](creating-clients.md#programmatic-config) client utilise des ressources indépendantes. Les ressources telles que les moteurs HTTP et les fournisseurs d'informations d'identification sont partagées à moins qu'elles ne soient remplacées dans le `withConfig` bloc. 

Le cycle de vie de chaque client étant indépendant, les ressources partagées restent ouvertes et utilisables jusqu'à la fermeture du dernier client. Par conséquent, il est important que vous fermiez les clients dont les services ont été annulés lorsque vous n'en avez plus besoin. Cela empêche les ressources partagées de rester ouvertes et de consommer des ressources système telles que la mémoire, la connexion et les cycles du processeur.

L'exemple suivant montre à la fois des ressources partagées et indépendantes.

Les `overriddenS3` clients `s3` et partagent la même instance de fournisseur d'informations d'identification, y compris sa configuration de mise en cache. Les appels effectués en `overriddenS3` réutilisant les informations d'identification si la valeur mise en cache est toujours à jour depuis les appels effectués par le `s3` client.

 Le moteur HTTP n'est pas partagé entre les deux clients. Chaque client dispose d'un moteur HTTP indépendant car celui-ci a été remplacé lors de l'`withConfig`appel.

```
val s3 = S3Client.fromEnvironment {
    region = "us-west-2"
    credentialsProvider = CachedCredentialsProvider(CredentialsProviderChain(...))
    httpClientEngine = OkHttpEngine { ... }
}

s3.listBuckets { ... }

s3.withConfig {
    httpClientEngine = CrtHttpEngine { ... }
}.use { overriddenS3 ->
    overriddenS3.listObjectsV2 { ... }
}
```