///

## Modèles Pydantic pour les formulaires { #pydantic-models-for-forms }

Vous avez simplement besoin de déclarer un **modèle Pydantic** avec les champs que vous souhaitez recevoir comme **champs de formulaire**, puis de déclarer le paramètre comme `Form` :

{* ../../docs_src/request_form_models/tutorial001_an_py310.py hl[9:11,15] *}

La <dfn title="spécification">spécification</dfn> exige que les champs soient exactement nommés `username` et `password`, et qu'ils soient envoyés en tant que champs de formulaire, pas en JSON.

Le *modèle de données* `HeroUpdate` est un peu spécial, il a **tous les mêmes champs** qui seraient nécessaires pour créer un nouveau héros, mais tous les champs sont **optionnels** (ils ont tous une valeur par défaut). Ainsi, lorsque vous mettez à jour un héros, vous pouvez n'envoyer que les champs que vous souhaitez mettre à jour.

Les fichiers et les champs de formulaire seront téléversés en tant que données de formulaire et vous les recevrez.

Et vous pouvez déclarer certains fichiers comme `bytes` et d'autres comme `UploadFile`.

/// warning | Alertes

### Annotations de type et outils { #type-annotations-and-tooling }

Voyons d'abord comment les éditeurs, mypy et autres outils considèreraient cela.

`BaseUser` a les champs de base. Puis `UserIn` hérite de `BaseUser` et ajoute le champ `password`, il inclura donc tous les champs des deux modèles.

Nous annotons le type de retour de la fonction en `BaseUser`, mais nous renvoyons en réalité une instance de `UserIn`.

| `terms_of_service` | `str` | Une URL vers les Conditions d’utilisation de l’API. Le cas échéant, il doit s’agir d’une URL. |

## Déclarer des champs de liste { #list-fields }

Vous pouvez définir un attribut comme étant un sous-type. Par exemple, une `list` Python :

{* ../../docs_src/body_nested_models/tutorial001_py310.py hl[12] *}

Cela fera de `tags` une liste, bien que le type des éléments de la liste ne soit pas déclaré.

## Champs de liste avec paramètre de type { #list-fields-with-type-parameter }

N'utilisez base64 que si vous devez absolument inclure des données binaires dans du JSON et que vous ne pouvez pas utiliser des fichiers pour cela.

## Pydantic `bytes` { #pydantic-bytes }

Vous pouvez déclarer un modèle Pydantic avec des champs `bytes`, puis utiliser `val_json_bytes` dans la configuration du modèle pour lui indiquer d'utiliser base64 pour valider les données JSON en entrée ; dans le cadre de cette validation, il décodera la chaîne base64 en octets.

///

## Que sont les Server-Sent Events ? { #what-are-server-sent-events }

SSE est un standard pour diffuser des données du serveur au client via HTTP.

Chaque événement est un petit bloc de texte avec des « champs » comme `data`, `event`, `id` et `retry`, séparés par des lignes vides.

Cela ressemble à ceci :

```
data: {"name": "Portal Gun", "price": 999.99}

data: {"name": "Plumbus", "price": 32.99}

```

# Corps - Champs { #body-fields }

De la même manière que vous pouvez déclarer des validations supplémentaires et des métadonnées dans les paramètres d'une fonction de chemin d'accès avec `Query`, `Path` et `Body`, vous pouvez déclarer des validations et des métadonnées à l'intérieur des modèles Pydantic en utilisant `Field` de Pydantic.

## Importer `Field` { #import-field }

D'abord, vous devez l'importer :