

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.

# Types scalaires dans GraphQL
<a name="scalars"></a>

Un type d'objet GraphQL a un nom et des champs, et ces champs peuvent avoir des sous-champs. En fin de compte, les champs d'un type d'objet doivent être résolus en types *scalaires*, qui représentent les feuilles de la requête. Pour plus d'informations sur les types d'objets et les scalaires, consultez [Schémas et types](https://graphql.org/learn/schema/) sur le site Web de GraphQL.

Outre l'ensemble par défaut de scalaires GraphQL, vous pouvez AWS AppSync également utiliser les scalaires **définis par le service qui commencent par** le préfixe. *AWS* AWS AppSync ne prend pas en charge la création de scalaires **définis par l'utilisateur** (personnalisés). Vous devez utiliser la valeur par défaut ou des *AWS*scalaires. 

Vous ne pouvez pas l'utiliser *AWS*comme préfixe pour les types d'objets personnalisés.

La section suivante est une référence pour la saisie de schémas.

## Scalaires par défaut
<a name="graph-ql-base-scalars"></a>

GraphQL définit les scalaires par défaut suivants :

### Liste des scalaires par défaut
<a name="graph-ql-base-scalars-list"></a>

`ID`  
Identifiant unique d'un objet. Ce scalaire est sérialisé comme un `String` mais n'est pas censé être lisible par l'homme.

`String`  
Une séquence de caractères UTF-8.

`Int`  
Une valeur entière comprise entre - (2 31) et 2 31 -1.

`Float`  
Une valeur à virgule flottante IEEE 754.

`Boolean`  
Une valeur booléenne, `true` ou `false`.

## AWS AppSync scalaires
<a name="graph-ql-aws-appsync-scalars"></a>

AWS AppSync définit les scalaires suivants :

### AWS AppSync liste de scalaires
<a name="graph-ql-aws-appsync-scalars-list"></a>

`AWSDate`  
Chaîne de [date ISO 8601](https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates) étendue au format`YYYY-MM-DD`.

`AWSTime`  
Chaîne [temporelle ISO 8601](https://en.wikipedia.org/wiki/ISO_8601#Times) étendue au format`hh:mm:ss.sss`.

`AWSDateTime`  
Chaîne de [date et d'heure ISO 8601](https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations) étendue au format`YYYY-MM-DDThh:mm:ss.sssZ`.

**Note**  
Les `AWSDateTime` scalaires `AWSDate``AWSTime`, et peuvent éventuellement inclure un [décalage de fuseau horaire](https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators). Par exemple, les valeurs `1970-01-01Z``1970-01-01-07:00`, et `1970-01-01+05:30` sont toutes valides pour`AWSDate`. Le décalage de fuseau horaire doit être soit `Z` (UTC), soit un décalage en heures et minutes (et éventuellement en secondes). Par exemple, `±hh:mm:ss`. Le champ des secondes dans le décalage horaire est considéré comme valide même s'il ne fait pas partie de la norme ISO 8601.

`AWSTimestamp`  
Une valeur entière représentant le nombre de secondes avant ou après`1970-01-01-T00:00Z`.

`AWSEmail`  
Une adresse e-mail au format `local-part@domain-part` défini par la [RFC 822](https://tools.ietf.org/html/rfc822).

`AWSJSON`  
Une chaîne JSON. Toute construction JSON valide est automatiquement analysée et chargée dans le code du résolveur sous forme de cartes, de listes ou de valeurs scalaires plutôt que sous forme de chaînes d'entrée littérales. Les chaînes sans guillemets ou le format JSON non valide entraînent une erreur de validation GraphQL.

`AWSPhone`  
Numéro de téléphone. Cette valeur est stockée sous forme de chaîne. Les numéros de téléphone peuvent contenir des espaces ou des traits d'union pour séparer les groupes de chiffres. Les numéros de téléphone sans code de pays sont supposés être des numéros américains ou nord-américains conformes au [plan de numérotation nord-américain (](https://en.wikipedia.org/wiki/North_American_Numbering_Plan)NANP).

`AWSURL`  
Une URL telle que définie par la [RFC 1738](https://tools.ietf.org/html/rfc1738). Par exemple, `https://www.amazon.com/dp/B000NZW3KC/` ou`mailto:example@example.com`. URLsdoit contenir un schéma (`http`,`mailto`) et ne peut pas contenir deux barres obliques (`//`) dans la partie chemin.

`AWSIPAddress`  
Une IPv6 adresse IPv4 ou une adresse valide. IPv4 les adresses sont attendues en notation à quatre points (). `123.12.34.56` IPv6 les adresses sont attendues dans un format non entre crochets et séparés par des deux-points (). `1a2b:3c4b::1234:4567` Vous pouvez inclure un suffixe CIDR facultatif (`123.45.67.89/16`) pour indiquer le masque de sous-réseau.

## Exemple d'utilisation du schéma
<a name="example-schema-usage"></a>

L'exemple de schéma GraphQL suivant utilise tous les scalaires personnalisés comme « objet » et montre les modèles de demande et de réponse du résolveur pour les opérations de base de type put, get et list. Enfin, l'exemple montre comment vous pouvez l'utiliser lors de l'exécution de requêtes et de mutations.

```
type Mutation {
    putObject(
        email: AWSEmail,
        json: AWSJSON,
        date: AWSDate,
        time: AWSTime,
        datetime: AWSDateTime,
        timestamp: AWSTimestamp,
        url: AWSURL,
        phoneno: AWSPhone,
        ip: AWSIPAddress
    ): Object
}

type Object {
    id: ID!
    email: AWSEmail
    json: AWSJSON
    date: AWSDate
    time: AWSTime
    datetime: AWSDateTime
    timestamp: AWSTimestamp
    url: AWSURL
    phoneno: AWSPhone
    ip: AWSIPAddress
}

type Query {
    getObject(id: ID!): Object
    listObjects: [Object]
}

schema {
    query: Query
    mutation: Mutation
}
```

Voici à quoi `putObject` pourrait ressembler un modèle de demande. A `putObject` utilise une `PutItem` opération pour créer ou mettre à jour un élément dans votre table Amazon DynamoDB. Notez que cet extrait de code ne contient pas de table Amazon DynamoDB configurée comme source de données. Ceci n'est utilisé qu'à titre d'exemple :

```
{
    "version" : "2017-02-28",
    "operation" : "PutItem",
    "key" : {
        "id": $util.dynamodb.toDynamoDBJson($util.autoId()),
    },
    "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```

Le modèle de réponse pour `putObject` renvoie les résultats :

```
$util.toJson($ctx.result)
```

Voici à quoi `getObject` pourrait ressembler un modèle de demande. A `getObject` utilise une `GetItem` opération pour renvoyer un ensemble d'attributs pour l'élément doté de la clé primaire. Notez que cet extrait de code ne contient pas de table Amazon DynamoDB configurée comme source de données. Ceci n'est utilisé qu'à titre d'exemple :

```
{
    "version": "2017-02-28",
    "operation": "GetItem",
    "key": {
        "id": $util.dynamodb.toDynamoDBJson($ctx.args.id),
    }
}
```

Le modèle de réponse pour `getObject` renvoie les résultats :

```
$util.toJson($ctx.result)
```

Voici à quoi `listObjects` pourrait ressembler un modèle de demande. A `listObjects` utilise une `Scan` opération pour renvoyer un ou plusieurs éléments et attributs. Notez que cet extrait de code ne contient pas de table Amazon DynamoDB configurée comme source de données. Ceci n'est utilisé qu'à titre d'exemple :

```
{
    "version" : "2017-02-28",
    "operation" : "Scan",
}
```

Le modèle de réponse pour `listObjects` renvoie les résultats :

```
$util.toJson($ctx.result.items)
```

Voici quelques exemples d'utilisation de ce schéma avec des requêtes GraphQL :

```
mutation CreateObject {
    putObject(email: "example@example.com"
        json: "{\"a\":1, \"b\":3, \"string\": 234}"
        date: "1970-01-01Z"
        time: "12:00:34."
        datetime: "1930-01-01T16:00:00-07:00"
        timestamp: -123123
        url:"https://amazon.com"
        phoneno: "+1 555 764 4377"
        ip: "127.0.0.1/8"
    ) {
        id
        email
        json
        date
        time
        datetime
        url
        timestamp
        phoneno
        ip
    }
}

query getObject {
    getObject(id:"0d97daf0-48e6-4ffc-8d48-0537e8a843d2"){
        email
        url
        timestamp
        phoneno
        ip
    }
}

query listObjects {
    listObjects {
        json
        date
        time
        datetime
    }
}
```