

 Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

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.

# Utilisation de l’API de données Amazon Redshift
<a name="data-api"></a>

L’API de données Amazon Redshift simplifie l’accès à votre entrepôt de données Amazon Redshift en éliminant le besoin de gérer les pilotes de base de données, les connexions, les configurations réseau, la mise en mémoire tampon des données, les informations d’identification, etc. Vous pouvez exécuter des instructions SQL à l'aide des opérations de l'API de données avec le AWS SDK. Pour plus d’informations sur les fonctions de l’API de données, consultez la [Référence de l’API de données Amazon Redshift](https://docs.aws.amazon.com/redshift-data/latest/APIReference/).

L’API de données ne nécessite pas de connexion permanente à votre base de données. Au lieu de cela, il fournit un point de terminaison HTTP sécurisé et une intégration avec AWS SDKs. Vous pouvez utiliser le point de terminaison pour exécuter des instructions SQL sans avoir à gérer de connexions. Les appels à l’API de données sont asynchrones. L'API de données peut utiliser des informations d'identification stockées dans AWS Secrets Manager ou des informations d'identification temporaires dans la base de données. Il n’est pas nécessaire de transmettre des mots de passe dans les appels d’API avec l’une ou l’autre méthode d’autorisation. Pour plus d'informations AWS Secrets Manager, voir [Qu'est-ce que c'est AWS Secrets Manager ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) dans le *guide de AWS Secrets Manager l'utilisateur*. Vous pouvez également utiliser AWS IAM Identity Center pour obtenir une autorisation.

Avec l'API Data, vous pouvez accéder par programmation aux données Amazon Redshift à l'aide d'applications basées sur des services Web AWS Lambda, notamment les blocs-notes Amazon SageMaker AI et. AWS Cloud9 Pour plus d'informations sur ces applications [AWS Lambda](https://aws.amazon.com/lambda/), consultez [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/) et [AWS Cloud9](https://aws.amazon.com/cloud9/). 

Pour en savoir plus sur l’API de données, consultez [Mise en route avec l’API de données Amazon Redshift](https://aws.amazon.com/blogs/big-data/get-started-with-the-amazon-redshift-data-api/) sur le le blog *AWS Big Data*.

## Utilisation de l’API de données Amazon Redshift
<a name="data-api-workflow"></a>

Avant d’utiliser l’API de données Amazon Redshift, passez en revue les étapes suivantes : 

1. Déterminez si vous, en tant qu’appelant de l’API de données, disposez des autorisations requises. Pour de plus amples informations concernant l’autorisation, consultez [Autorisation de l’accès à l’API de données Amazon Redshift](data-api-access.md).

1. Déterminez si vous prévoyez d’appeler l’API de données avec les informations d’identification d’authentification de Secrets Manager, avec des informations d’identification temporaires ou avec AWS IAM Identity Center. Pour de plus amples informations, veuillez consulter [Choix des informations d’authentification de la base de données lors de l’appel de l’API de données Amazon Redshift.](#data-api-calling-considerations-authentication).

1. Configurez un secret si vous utilisez Secrets Manager pour les informations d’identification d’authentification. Pour plus d’informations, consultez [Stockage des identifiants de base de données dans AWS Secrets Manager](data-api-secrets.md).

1. Passez en revue les considérations et les limitations lors de l’appel de l’API de données. Pour de plus amples informations, veuillez consulter [Considérations relatives à l’appel à l’API de données Amazon Redshift](#data-api-calling-considerations).

1. Appelez l'API Data depuis AWS Command Line Interface (AWS CLI), depuis votre propre code ou à l'aide de l'éditeur de requêtes de la console Amazon Redshift. Pour obtenir des exemples d’appel depuis AWS CLI, consultez [Appel à l’API de données](data-api-calling.md).

## Considérations relatives à l’appel à l’API de données Amazon Redshift
<a name="data-api-calling-considerations"></a>

Tenez compte des éléments suivants lorsque vous appelez l’API de données :
+ L’API de données Amazon Redshift peut accéder aux bases de données dans les clusters Amazon Redshift provisionnés et les groupes de travail Redshift sans serveur. Pour obtenir la liste des Régions AWS endroits où l'API Redshift Data est disponible, consultez les points de terminaison répertoriés pour l'API [Redshift](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) Data dans le. *Référence générale d'Amazon Web Services* 
+ La durée maximale d’une requête est de 24 heures. 
+ Le nombre maximum de requêtes (`STARTED`et `SUBMITTED` requêtes) actives par cluster Amazon Redshift est de 500. 
+ La taille maximale du résultat de requête est de 500 Mo (après compression gzip). Si un appel renvoie plus de 500 Mo de données de réponse, l'appel est terminé. 
+ La durée maximale de conservation des résultats de la requête est de 24 heures. 
+ La taille maximale de l’instruction de requête est de 100 Ko. 
+ L’API de données est à même de lancer des requêtes sur des clusters à un ou plusieurs nœuds des types de nœuds suivants :
  + dc2.large
  + dc2.8xlarge
  + ra3.large
  + ra3.xlplus
  + ra3.4xlarge
  + ra3.16xlarge
+ Le clusters doit être dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. 
+ Par défaut, les utilisateurs ayant le même rôle IAM que l’exécutant d’une fonction API `ExecuteStatement` ou `BatchExecuteStatement` peuvent agir sur la même déclaration avec des fonctions API `CancelStatement`, `DescribeStatement`, `GetStatementResult`, `GetStatementResultV2` et `ListStatements`. Pour agir sur la même instruction SQL provenant d’un autre utilisateur, l’utilisateur doit pouvoir assumer le rôle IAM de l’utilisateur qui a exécuté l’instruction SQL. Pour plus d’informations sur la façon d’assumer un rôle, consultez [Autorisation de l’accès à l’API de données Amazon Redshift](data-api-access.md). 
+ Les instructions SQL du paramètre `Sqls` de l’opération d’API `BatchExecuteStatement` sont exécutées en tant que transaction unique. Ils s’exécutent en série dans l’ordre du tableau. Les instructions SQL suivantes ne démarrent pas tant que l’instruction précédente du tableau n’est pas terminée. Si une instruction SQL échoue, c’est parce qu’elle est exécutée comme une seule transaction que tout le travail est annulé.
+ La durée de conservation maximale d’un jeton client utilisé dans une opération d’API `ExecuteStatement` ou `BatchExecuteStatement` est de 8 heures.
+ Si les clusters provisionnés par Amazon Redshift et le groupe de travail Redshift Serverless sont chiffrés à l'aide d'une clé gérée par le client, Redshift crée une autorisation qui permet à l'API Redshift Data d'utiliser la clé pour ses opérations. Pour plus d'informations, consultez [Utilisation AWS KMS avec l'API de données Amazon Redshift](data-api-kms.md). 
+ Chaque API de l’API de données Redshift dispose d’un quota de transactions par seconde avant de limiter les demandes. Pour ce quota, consultez [Quotas pour l’API de données Amazon Redshift](amazon-redshift-limits.md#data-api-quotas-account). Si le taux de demande dépasse le quota, une exception `ThrottlingException` avec le code d’état HTTP : 400 est renvoyée. Pour répondre à la limitation, utilisez une stratégie de nouvelle tentative telle que décrite dans la section [Comportement des nouvelles tentatives](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) dans le guide de référence *AWS SDKs and* Tools. Cette stratégie est mise en œuvre automatiquement pour limiter les erreurs dans certains cas. AWS SDKs
**Note**  
Par défaut AWS Step Functions, les nouvelles tentatives ne sont pas activées. Si vous devez appeler une API de données Redshift dans une machine d’état Step Functions, incluez le paramètre d’idempotence `ClientToken` dans votre appel d’API de données Redshift. La valeur de `ClientToken` doit être conservée entre les nouvelles tentatives. Dans l’exemple d’extrait suivant d’une demande adressée à l’API `ExecuteStatement`, l’expression `States.ArrayGetItem(States.StringSplit($$.Execution.Id, ':'), 7)` utilise une fonction intrinsèque pour extraire la partie UUID de `$$.Execution.Id`, qui est unique pour chaque exécution de la machine d’état. Pour plus d’informations, consultez [Fonctions intrinsèques](https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-intrinsic-functions.html) dans le *Guide du développeur AWS Step Functions *.  

  ```
  {
    "Database": "dev",
    "Sql": "select 1;",
    "ClusterIdentifier": "MyCluster",
    "ClientToken.$": "States.ArrayGetItem(States.StringSplit($$.Execution.Id, ':'), 7)"
  }
  ```

## Choix des informations d’authentification de la base de données lors de l’appel de l’API de données Amazon Redshift.
<a name="data-api-calling-considerations-authentication"></a>

Lorsque vous appelez l’API de données, vous utilisez l’une des méthodes d’authentification suivantes pour certaines fonctions de l’API. Chaque méthode nécessite une combinaison différente de paramètres. 

**AWS IAM Identity Center**  
L’API de données est accessible avec un utilisateur à authentification unique enregistré dans AWS IAM Identity Center. Pour plus d’informations sur les étapes de configuration d’IAM Identity Center, consultez [Utilisation de l’API de données avec la propagation d’identité de confiance](data-api-trusted-identity-propagation.md).

**AWS Secrets Manager**  
Avec cette méthode, fournissez `secret-arn` le secret stocké dans AWS Secrets Manager lequel a `username` et`password`. Le secret spécifié contient des informations d’identification pour vous connecter à la `database` que vous spécifiez. Lorsque vous vous connectez à un cluster, vous fournissez également le nom de la base de données, Si vous fournissez un identifiant de cluster (`dbClusterIdentifier`), il doit correspondre à l’identifiant de cluster stocké dans le secret. Lorsque vous vous connectez à un groupe de travail sans serveur, vous devez également fournir le nom de la base de données. Pour de plus amples informations, veuillez consulter [Stockage des identifiants de base de données dans AWS Secrets Manager](data-api-secrets.md).   
Avec cette méthode, vous pouvez également fournir une `region` valeur qui indique l' Région AWS emplacement de vos données. 

**Informations d’identification temporaires**  
Avec cette méthode, choisissez l’une des options suivantes :  
+ Lors de la connexion à un groupe de travail sans serveur, indiquez le nom du groupe de travail et le nom de la base de données. Le nom de l’utilisateur de la base de données est dérivé de l’identité IAM. Par exemple, `arn:iam::123456789012:user:foo` a le nom d’utilisateur de la base de données `IAM:foo`. De plus, l’autorisation d’appeler l’opération `redshift-serverless:GetCredentials` est requise.
+ Lorsque vous vous connectez à un cluster en tant qu’identité IAM, indiquez l’identifiant du cluster et le nom de la base de données. Le nom de l’utilisateur de la base de données est dérivé de l’identité IAM. Par exemple, `arn:iam::123456789012:user:foo` a le nom d’utilisateur de la base de données `IAM:foo`. De plus, l’autorisation d’appeler l’opération `redshift:GetClusterCredentialsWithIAM` est requise.
+ Lorsque vous vous connectez à un cluster en tant qu’utilisateur de base de données, indiquez l’identifiant du cluster, le nom de la base de données et le nom de l’utilisateur de la base de données. De plus, l’autorisation d’appeler l’opération `redshift:GetClusterCredentials` est requise. Pour savoir comment rejoindre des groupes de base de données lors de la connexion avec cette méthode, consultez [Rejoindre des groupes de base de données lors de la connexion à un cluster](data-api-dbgroups.md).
Avec cette méthode, vous pouvez également fournir une `region` valeur qui indique l' Région AWS emplacement de vos données. 

## Mappage de types de données JDBC lors de l’appel à l’API de données Amazon Redshift
<a name="data-api-calling-considerations-jdbc"></a>

 Le tableau suivant associe les types de données Java Database Connectivity (JDBC) aux types de données que vous spécifiez dans les appels d’API de données.


****  

|  Type de données JDBC  |  Type de données API de données  | 
| --- | --- | 
| `INTEGER, SMALLINT, BIGINT` | `LONG` | 
| `FLOAT, REAL, DOUBLE` | `DOUBLE` | 
| `DECIMAL` | `STRING` | 
| `BOOLEAN, BIT` | `BOOLEAN` | 
| `BLOB, BINARY, LONGVARBINARY` | `BLOB` | 
| `VARBINARY` | `STRING` | 
| `CLOB` | `STRING` | 
| Autres types (y compris les types liés à la date et à l’heure) | `STRING` | 

Les valeurs de chaîne de caractères sont transmises à la base de données Amazon Redshift et implicitement converties en un type de données de base de données.

**Note**  
Actuellement, l'API Data ne prend pas en charge les tableaux d'identifiants uniques universels ()UUIDs.

## Exécution d’instructions SQL avec des paramètres lors de l’appel à l’API de données Amazon Redshift
<a name="data-api-calling-considerations-parameters"></a>

Vous pouvez contrôler le texte SQL soumis au moteur de la base de données en appelant la fonction de l’API de données tout en utilisant des paramètres pour les parties de l’instruction SQL. Les paramètres nommés constituent un moyen flexible de passer des paramètres sans les coder en dur dans le texte. Ils vous aident à réutiliser le texte SQL et à éviter les problèmes d’injection SQL.

L'exemple suivant montre les paramètres nommés d'un `parameters` champ d'une `batch-execute-statement` AWS CLI commande `execute-statement` or.

```
--parameters "[{\"name\": \"id\", \"value\": \"1\"},{\"name\": \"address\", \"value\": \"Seattle\"}]"
```

Tenez compte des éléments suivants lorsque vous utilisez des paramètres nommés :
+ Les paramètres nommés ne peuvent être utilisés que pour remplacer des valeurs dans les instructions SQL.
  + Vous pouvez remplacer les valeurs d’une instruction INSERT, telle que `INSERT INTO mytable VALUES(:val1)`.

    Les paramètres nommés peuvent être dans n’importe quel ordre et ils peuvent être utilisés plusieurs fois dans le texte SQL. L’option de paramétrage présentée dans un précédent exemple, les valeurs `1` et `Seattle` sont insérées dans les colonnes `id` et `address` de la table. Dans le texte SQL, vous spécifiez les paramètres nommés comme suit :

    ```
    --sql "insert into mytable values (:id, :address)"
    ```
  + Vous pouvez remplacer les valeurs dans une clause de condition, telle que `WHERE attr >= :val1`, `WHERE attr BETWEEN :val1 AND :val2` et `HAVING COUNT(attr) > :val`.
  + Vous ne pouvez pas remplacer les noms de colonnes dans une instruction SQL, tels que `SELECT column-name`, `ORDER BY column-name`, ou `GROUP BY column-name`.

    Par exemple, l’instruction SELECT suivante échoue en raison d’une syntaxe non valide.

    ```
    --sql "SELECT :colname, FROM event" --parameters "[{\"name\": \"colname\", \"value\": \"eventname\"}]"
    ```

    Si vous décrivez (opération `describe-statement`) l’instruction avec l’erreur de syntaxe, la commande `QueryString` renvoyée ne remplace pas le nom de la colonne par le paramètre (`"QueryString": "SELECT :colname, FROM event"`) et une erreur est signalée (ERREUR : erreur de syntaxe à ou près de « FROM » Position : 12).
  + Vous ne pouvez pas remplacer les noms de colonnes dans une fonction d’agrégation, tels que `COUNT(column-name)`, `AVG(column-name)`, ou `SUM(column-name)`.
  + Vous ne pouvez pas remplacer les noms de colonnes dans une clause JOIN.
+ Lorsque le SQL s’exécute, les données sont implicitement converties en un type de données. Pour plus d’informations sur le moulage des types de données, consultez [Types de données](https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html) dans le *Manuel du développeur de base de données Amazon Redshift*. 
+ Vous ne pouvez pas définir une valeur sur NULL. L’API de données l’interprète comme la chaîne littérale `NULL`. L’exemple suivant remplace `id` par la chaîne littérale `null`. Pas la valeur SQL NULL. 

  ```
  --parameters "[{\"name\": \"id\", \"value\": \"null\"}]"
  ```
+ Vous ne pouvez pas définir une valeur de longueur de zéro. L’instruction SQL de l’API de données échoue. L’exemple suivant tente de définir `id` avec une valeur de longueur de zéro et se solde par un échec de l’instruction SQL. 

  ```
  --parameters "[{\"name\": \"id\", \"value\": \"\"}]"
  ```
+ Vous ne pouvez pas définir un nom de table dans l’instruction SQL avec un paramètre. L’API de données suit la règle du JDBC `PreparedStatement`. 
+ La sortie de l’opération `describe-statement` renvoie les paramètres de requête d’une instruction SQL.
+ Les `batch-execute-statement` opérations `execute-statement` et prennent toutes deux en charge les instructions SQL avec paramètres. Lors de l'utilisation`batch-execute-statement`, les paramètres sont partagés entre toutes les instructions SQL du lot. Chaque instruction SQL peut faire référence à un sous-ensemble des paramètres fournis, mais chaque paramètre doit être utilisé par au moins une instruction SQL.

## Exécution d’instructions SQL avec un jeton d’idempotence lors de l’appel à l’API de données Amazon Redshift
<a name="data-api-calling-considerations-idempotency"></a>

Lorsque vous effectuez une demande d’API de mutation, la demande renvoie généralement un résultat avant la fin des flux de travail asynchrones de l’opération. Les opérations peuvent également expirer ou rencontrer d’autres problèmes de serveur avant d’être terminées, même si la demande a déjà renvoyé un résultat. Par conséquent, il peut être difficile de déterminer si la demande a abouti ou non et de multiples tentatives peuvent être déclenchées pour s’assurer que l’opération se termine correctement. Toutefois, si la demande initiale et les tentatives suivantes aboutissent, l’opération est terminée plusieurs fois. Vous pouvez ainsi mettre à jour plus de ressources que prévu.

L’*idempotence* garantit qu’une demande d’API se termine correctement. Avec une demande idempotente, si la demande d’origine se termine avec succès, toutes les tentatives suivantes se terminent avec succès, sans aucune action supplémentaire. Les opérations `ExecuteStatement` et `BatchExecuteStatement` de l’API de données ont un paramètre idempotent `ClientToken` facultatif. Le `ClientToken` expire au bout de 8 heures.

**Important**  
Si vous appelez `ExecuteStatement` et effectuez `BatchExecuteStatement` des opérations à partir d'un AWS SDK, celui-ci génère automatiquement un jeton client à utiliser lors d'une nouvelle tentative. Dans ce cas, nous ne recommandons pas d’utiliser le paramètre `client-token` avec les opérations `ExecuteStatement` et `BatchExecuteStatement`. Consultez le CloudTrail journal pour voir le`ClientToken`. Pour un exemple de CloudTrail journal, voir[Exemples d’API de données Amazon Redshift](logging-with-cloudtrail.md#data-api-cloudtrail).

La `execute-statement` AWS CLI commande suivante illustre le `client-token` paramètre facultatif pour l'idempotentie.

```
aws redshift-data execute-statement 
    --secret-arn arn:aws:secretsmanager:us-west-2:123456789012:secret:myuser-secret-hKgPWn 
    --cluster-identifier mycluster-test 
    --sql "select * from stl_query limit 1" 
    --database dev 
    --client-token b855dced-259b-444c-bc7b-d3e8e33f94g1
```

La table suivante présente certaines réponses courantes que vous pouvez obtenir pour les demandes d’API idempotentes et fournit des recommandations pour réessayer.


| Réponse | Recommendation | Commentaires | 
| --- | --- | --- | 
| 200 (OK) | Ne pas réessayer | La demande d’origine s’est terminée avec succès. Toutes les tentatives suivantes sont renvoyées avec succès. | 
| Codes de réponse de la série 400  | Ne pas réessayer | La demande présente un problème, parmi les suivants : [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/data-api.html)<br />Si la demande concerne une ressource en train de changer d’état, il est possible que la nouvelle tentative aboutisse. | 
| Codes de réponse de la série 500  | Réessayer | L'erreur est due à un problème AWS côté serveur et est généralement transitoire. Répétez la demande avec une stratégie de backoff appropriée. | 

Pour plus d’informations sur les codes de réponse Amazon Redshift, consultez [Common Errors](https://docs.aws.amazon.com/redshift/latest/APIReference/CommonErrors.html) (Erreurs courantes) dans la *référence d’API Amazon Redshift*.

## Exécution d’instructions SQL avec réutilisation de session lors de l’appel à l’API de données Amazon Redshift
<a name="data-api-calling-considerations-session-reuse"></a>

Lorsque vous faites une demande d’API pour exécuter une instruction SQL, la session pendant laquelle le SQL s’exécute est généralement interrompue lorsque le SQL est terminé. Pour que la session reste active pendant un certain nombre de secondes, les opérations d’API de données `ExecuteStatement` et `BatchExecuteStatement` ont un paramètre `SessionKeepAliveSeconds` facultatif. Un champ de réponse `SessionId` contient l’identité de la session qui peut ensuite être utilisée dans les opérations `ExecuteStatement` et `BatchExecuteStatement` suivantes. Lors des appels suivants, vous pouvez en spécifier un autre `SessionKeepAliveSeconds` pour modifier le délai d’inactivité. Si le `SessionKeepAliveSeconds` n’est pas modifié, le paramètre de délai d’inactivité initial est conservé. Tenez compte des éléments suivants lorsque vous utilisez la réutilisation de session :
+ La valeur maximale de `SessionKeepAliveSeconds` est de 24 heures.
+ La session peut durer 24 heures au maximum. Après 24 heures, la session est fermée de force et les requêtes en cours sont interrompues.
+ Le nombre maximum de sessions par cluster Amazon Redshift ou groupe de travail Redshift sans serveur est de 500.
+ Vous ne pouvez exécuter qu’une seule requête à la fois dans une session. Vous devez attendre la fin de la requête pour exécuter la requête suivante au cours de la même session. En d’autres termes, vous ne pouvez pas exécuter de requêtes en parallèle dans une session donnée.
+ L’API de données ne peut pas mettre les requêtes en file d’attente pour une session donnée.

Pour récupérer l’`SessionId` utilisé par les appels aux opérations `ExecuteStatement` et `BatchExecuteStatement`, l’appel `DescribeStatement` et les opérations `ListStatements`.

L’exemple suivant montre comment utiliser les paramètres `SessionKeepAliveSeconds` et `SessionId` pour maintenir une session active et la réutiliser. Appelez d'abord la `execute-statement` AWS CLI commande avec le `session-keep-alive-seconds` paramètre optionnel défini sur`2`.

```
aws redshift-data execute-statement 
    --session-keep-alive-seconds 2 
    --sql "select 1" 
    --database dev 
    --workgroup-name mywg
```

La réponse contient l’identifiant de session.

```
{
    "WorkgroupName": "mywg",
    "CreatedAt": 1703022996.436,
    "Database": "dev",
    "DbUser": "awsuser",
    "Id": "07c5ffea-76d6-4786-b62c-4fe3ef529680",
    "SessionId": "5a254dc6-4fc2-4203-87a8-551155432ee4"
}
```

Appelez ensuite la `execute-statement` AWS CLI commande avec le résultat `SessionId` renvoyé par le premier appel. Et éventuellement, spécifiez le paramètre `session-keep-alive-seconds` défini sur `10` pour modifier la valeur du délai d’inactivité.

```
aws redshift-data execute-statement 
    --sql "select 1" 
    --session-id 5a254dc6-4fc2-4203-87a8-551155432ee4
    --session-keep-alive-seconds 10
```

## Récupération des résultats des instructions SQL
<a name="data-api-calling-considerations-result-format"></a>

Vous utilisez différentes opérations de l’API de données pour récupérer les résultats SQL en fonction du format des résultats. Lorsque vous appelez `ExecuteStatement` et effectuez les opérations `BatchExecuteStatement`, vous pouvez spécifier si les résultats sont au format JSON ou CSV. Si vous ne spécifiez rien, le format par défaut est JSON. Pour récupérer les résultats JSON, utilisez l’opération `GetStatementResult`. Pour récupérer les résultats CSV, utilisez l’opération `GetStatementResultV2`.

Les résultats renvoyés au format JSON sont des enregistrements qui incluent des métadonnées relatives à chaque colonne. Chaque enregistrement est au format JSON. Par exemple, la réponse de `GetStatementResult` ressemble à ceci :

```
{
   "ColumnMetadata": [ 
      { 
         "isCaseSensitive": false,
         "isCurrency": false,
         "isSigned": true,
         "label": "?column?",
         "name": "?column?",
         "nullable": 1,
         "precision": 10,
         "scale": 0,
         "schemaName": "",
         "tableName": "",
         "typeName": "int4",
         "length": 0
      }
   ],
   "NextToken": "{{<token>}}",
   "Records": [
        [
            {
                "longValue": 1
            }
        ]
    ],
   "TotalNumRows": {{<number>}}
}
```

Les résultats renvoyés au format CSV sont des enregistrements qui incluent des métadonnées relatives à chaque colonne. Les résultats sont renvoyés sous forme de blocs de 1 Mo, chaque bloc pouvant stocker un nombre illimité de lignes au format CSV. Chaque requête renvoie jusqu’à 15 Mo de résultats. Si les résultats sont supérieurs à 15 Mo, un jeton de page suivante est renvoyé pour continuer à récupérer les résultats. Par exemple, la réponse de `GetStatementResultV2` ressemble à ceci :

```
{
    "ColumnMetadata": [
        {
            "isCaseSensitive": false,
            "isCurrency": false,
            "isSigned": true,
            "label": "?column?",
            "name": "?column?",
            "nullable": 1,
            "precision": 10,
            "scale": 0,
            "schemaName": "",
            "tableName": "",
            "typeName": "int4",
            "length": 0
        },
        {
            "isCaseSensitive": false,
            "isCurrency": false,
            "isSigned": true,
            "label": "?column?",
            "name": "?column?",
            "nullable": 1,
            "precision": 10,
            "scale": 0,
            "schemaName": "",
            "tableName": "",
            "typeName": "int4",
            "length": 0
        },
        {
            "isCaseSensitive": false,
            "isCurrency": false,
            "isSigned": true,
            "label": "?column?",
            "name": "?column?",
            "nullable": 1,
            "precision": 10,
            "scale": 0,
            "schemaName": "",
            "tableName": "",
            "typeName": "int4",
            "length": 0
        }
    ],
    "NextToken": "{{<token>}}",
    "Records": [
        [
            {
                "CSVRecords":"1,2,3\r\n4,5,6\r\n7,8,9\rn, .... 1MB" // First 1MB Chunk
            },
            {
                "CSVRecords":"1025,1026,1027\r\n1028,1029,1030\r\n....2MB" // Second 1MB chunk
            }
            ...
        ]
    ],
    "ResultFormat" : "CSV",
    "TotalNumRows": {{<number>}}
}
```