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.

# Comparaison des comportements de l’API de données Amazon RDS entre Aurora Serverless v2 et les clusters provisionnés avec les clusters Aurora Serverless v1
<a name="data-api.differences"></a>

Les dernières améliorations apportées aux API de données Amazon RDS les rendent compatibles avec les clusters fonctionnant sur les versions récentes des moteurs PostgreSQL ou MySQL. Ces clusters peuvent être configurés pour utiliser Aurora Serverless v2 ou provisionner des classes d’instance telles que `db.r6g` ou `db.r6i`.

Les sections suivantes décrivent les différences de l’API de données Amazon RDS entre Aurora Serverless v2 et les clusters de bases de données provisionnés, ainsi que les clusters de bases de données Aurora Serverless v1. Les clusters de bases de données Aurora Serverless v1 utilisent le mode moteur `serverless`. Les clusters de bases de données provisionnés utilisent le mode moteur `provisioned`. Un cluster de bases de données Aurora Serverless v2 utilise le mode moteur `provisioned` et contient une ou plusieurs instances de base de données Aurora Serverless v2 avec la classe d’instance `db.serverless`.

## Nombre maximal de demandes par seconde
<a name="data-api.differences-requests"></a>

**Aurora Serverless v1**

Les API de données peuvent traiter jusqu’à 1 000 demandes par seconde.

**Aurora Serverless v2**

Les API de données peuvent traiter un nombre illimité de demandes par seconde.

## Activation ou désactivation de l’API de données Amazon RDS sur une base de données existante
<a name="data-api.differences-enable-disable"></a>

**Aurora Serverless v1**
+ **Avec l’API Amazon RDS** : utilisez l’opération `ModifyCluster` et indiquez `True` ou `False`, selon le cas, pour le paramètre `EnableHttpEndpoint`.
+ **Avec AWS CLI** : utilisez l’opération `modify-db-cluster` avec l’option `--enable-http-endpoint` ou `--no-enable-http-endpoint`, selon le cas.

**Aurora Serverless v2**
+ **Avec l’API Amazon RDS** : utilisez les opérations `EnableHttpEndpoint` et `DisableHttpEndpoint`.
+ **Avec AWS CLI** : utilisez les opérations `enable-http-endpoint` et `disable-http-endpoint`.

## Événements CloudTrail
<a name="data-api.differences-ct-events"></a>

**Aurora Serverless v1**

Les événements provenant des appels de l’API de données sont des événements de gestion. Par défaut, ces événements sont consignés automatiquement dans un journal d’activité. Pour plus d’informations, consultez [Exclure les événements de l'API de données AWS CloudTrail d'un historique (Aurora Serverless v1uniquement)](logging-using-cloudtrail-data-api.md#logging-using-cloudtrail-data-api.excluding-cloudtrail-events).

**Aurora Serverless v2**

Les événements provenant des appels de l’API de données sont des événements de données. Par défaut, ces événements sont automatiquement exclus du journal d’activité. Pour plus d’informations, consultez [Inclure les événements de l'API de données dans un AWS CloudTrail historique](logging-using-cloudtrail-data-api.md#logging-using-cloudtrail-data-api.including-cloudtrail-events).

## Prise en charge d’instructions multiples
<a name="data-api.differences-multistatement"></a>

**Aurora Serverless v1**
+ Les instructions multiples ne sont pas prises en charge avec Aurora MySQL.
+ Les instructions multiples renvoient uniquement la première réponse à la requête dans Aurora PostgreSQL.

**Aurora Serverless v2**

Les instructions multiples ne sont pas prises en charge. Toute tentative d’exécution d’instructions multiples dans un seul appel d’API renvoie `“An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.”`. Pour exécuter des instructions multiples, effectuez des appels d’API `ExecuteStatement` distincts ou utilisez `BatchExecuteStatement` pour le traitement par lots.

L’exemple suivant illustre le message d’erreur renvoyé par un appel d’API qui tente d’exécuter une instruction multiple.

```
 aws rds-data execute-statement \    
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
    --database "your_database" \
    --sql "SELECT * FROM your_table; Select * FROM next_table;
                                
                                "An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.
```

L’exemple suivant exécute des instructions multiples avec des appels d’API `ExecuteStatement` distincts.

```
aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM your_table;"

aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM next_table;"
```

## Demandes simultanées pour le même ID de transaction
<a name="data-api.differences-concurrent-requests-transaction"></a>

**Aurora Serverless v1**

Les demandes suivantes sont mises en attente jusqu’à ce que la demande en cours soit achevée. Votre application doit traiter les erreurs de délai d’expiration en cas d’attente prolongée.

**Aurora Serverless v2**

Lorsque l’API de données reçoit plusieurs demandes avec le même ID de transaction, elle renvoie immédiatement cette erreur :

`DatabaseErrorException: Transaction is still running a query`

Cette erreur se produit dans deux situations :
+ Votre application effectue des demandes asynchrones (comme des promesses JavaScript) en utilisant le même ID de transaction.
+ Une demande précédente avec cet ID de transaction est toujours en cours de traitement.

L’exemple suivant illustre toutes les demandes exécutées en parallèle avec `promise.all()`.

```
const api_calls = [];
for (let i = 0; i < 10; i++) {
api_calls.push(
    client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    )
);
}
await Promise.all(api_calls);
```

Pour résoudre cette erreur, attendez que la demande en cours se termine avant d’envoyer une autre demande avec le même ID de transaction, ou supprimez l’ID de transaction afin d’autoriser les demandes parallèles.

L’exemple suivant illustre un appel d’API qui utilise une exécution séquentielle avec le même ID de transaction.

```
 for (let i = 0; i < 10; i++) {
    await client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    ).promise()
);
}
```

## Comportement de l’instruction BatchExecuteStatement
<a name="data-api.differences-batchExecuteStatement"></a>

Pour plus d’informations sur l’instruction `BatchExecuteStatement`, consultez [BatchExecuteStatement](https://docs.aws.amazon.com/rdsdataservice/latest/APIReference/API_BatchExecuteStatement.html).

**Aurora Serverless v1**

L’objet des champs générés dans le résultat de la mise à jour inclut les valeurs insérées.

**Aurora Serverless v2**
+ L’objet des champs générés dans le résultat de la mise à jour inclut les valeurs insérées dans Aurora MySQL.
+ L’objet des champs générés est vide dans Aurora PostgreSQL.

## Comportement de l’instruction ExecuteSQL
<a name="data-api.differences-ExecuteSQL"></a>

Pour plus d’informations sur l’instruction `ExecuteSQL`, consultez [ExecuteSQL](https://docs.aws.amazon.com/rdsdataservice/latest/APIReference/API_ExecuteSql.html).

**Aurora Serverless v1**

L’opération `ExecuteSQL` est obsolète.

**Aurora Serverless v2**

L’opération `ExecuteSQL` n’est pas prise en charge.

## Comportement de l’instruction ExecuteStatement
<a name="data-api.differences-ExecuteStatement"></a>

Pour plus d’informations sur l’instruction `ExecuteStatement`, consultez [ExecuteStatement](https://docs.aws.amazon.com/rdsdataservice/latest/APIReference/API_ExecuteStatement.html).

**Aurora Serverless v1**

Le paramètre `ExecuteStatement` prend en charge la récupération de colonnes de tableaux multidimensionnels ainsi que de tous les types de données avancés.

**Aurora Serverless v2**

Le paramètre `ExecuteStatement` ne prend pas en charge les colonnes de tableaux multidimensionnels. Certains types de données PostgreSQL ne sont également pas pris en charge, en particulier les types géométriques et les types monétaires. Lorsqu’une API de données rencontre un type de données non pris en charge, elle renvoie cette erreur : `UnsupportedResultException: The result contains the unsupported data type data_type`.

Pour contourner ce problème, convertissez le type de données non pris en charge en `TEXT`. L’exemple suivant convertit un type de données non pris en charge en `TEXT`.

```
SELECT custom_type::TEXT FROM my_table;-- 
ORSELECT CAST(custom_type AS TEXT) FROM my_table;
```

Pour obtenir la liste des types de données pris en charge pour chaque moteur de base de données Aurora, consultez [Référence des opérations de l’API de données](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html#data-api-operations).

## Comportement des paramètres de schéma
<a name="data-api.differences-schema-parameter"></a>

**Aurora Serverless v1**

Le paramètre `Schema` n’est pas pris en charge. Si le paramètre `Schema` est inclus dans un appel d’API, il est ignoré par l’API de données.

**Aurora Serverless v2**

Le paramètre `Schema` est obsolète. Si le paramètre `Schema` est inclus dans un appel d’API, l’API de données renvoie l’erreur suivante : `ValidationException: The schema parameter isn't supported`. L’exemple suivant illustre un appel de l’API de données qui renvoie l’erreur `ValidationException`.

```
aws rds-data execute-statement \
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
--database "your_database" \
--schema "your_schema" \
--sql "SELECT * FROM your_table LIMIT 10"
```

Pour résoudre ce problème, supprimez le paramètre `Schema` de votre appel d’API.

L’exemple suivant illustre un appel de l’API de données où le paramètre `Schema` a été supprimé.

```
aws rds-data execute-statement \   
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
--database "your_database" \    
--sql "SELECT * FROM your_table LIMIT 10"
```