Vous pouvez également retourner des modèles Pydantic (vous en verrez plus à ce sujet plus tard).

Il existe de nombreux autres objets et modèles qui seront automatiquement convertis en JSON (y compris des ORM, etc.). Essayez d’utiliser vos favoris, il est fort probable qu’ils soient déjà pris en charge.

### Étape 6 : le déployer { #step-6-deploy-it }

* Ces schémas participeront à la constitution du schéma généré OpenAPI, et seront utilisés par les documentations automatiques <abbr title="User Interfaces - Interfaces utilisateur">UIs</abbr>.

## Documentation automatique { #automatic-docs }

Les schémas JSON de vos modèles seront intégrés au schéma OpenAPI global de votre application, et seront donc affichés dans la documentation interactive de l'API :

Vous pouvez déclarer `examples` pour un modèle Pydantic qui seront ajoutés au JSON Schema généré.

{* ../../docs_src/schema_extra_example/tutorial001_py310.py hl[13:24] *}

Ces informations supplémentaires seront ajoutées telles quelles au **JSON Schema** de sortie pour ce modèle, et elles seront utilisées dans la documentation de l'API.

Le *décorateur de chemin d'accès* accepte un argument optionnel `dependencies`.

Il doit s'agir d'une `list` de `Depends()` :

{* ../../docs_src/dependencies/tutorial006_an_py310.py hl[19] *}

Ces dépendances seront exécutées/résolues de la même manière que des dépendances normales. Mais leur valeur (si elles en retournent une) ne sera pas transmise à votre *fonction de chemin d'accès*.

/// tip | Astuce

Dans ce cas, comme les deux modèles sont différents, si nous annotions le type de retour de la fonction en `UserOut`, l’éditeur et les outils se plaindraient que nous renvoyons un type invalide, car ce sont des classes différentes.

C'est pourquoi, dans cet exemple, nous devons le déclarer dans le paramètre `response_model`.

... mais continuez à lire ci-dessous pour voir comment contourner cela.

Ils seront détectés par leur nom :

{* ../../docs_src/query_params/tutorial004_py310.py hl[6,8] *}

## Paramètres de requête requis { #required-query-parameters }

Quand vous déclarez une valeur par défaut pour des paramètres qui ne sont pas des paramètres de chemin (pour l'instant, nous n'avons vu que les paramètres de requête), alors ils ne sont pas requis.

Ainsi, le préfixe dans ce cas est `/items`.

Nous pouvons également ajouter une liste de `tags` et des `responses` supplémentaires qui seront appliqués à tous les *chemins d'accès* inclus dans ce routeur.

Et nous pouvons ajouter une liste de `dependencies` qui seront ajoutées à tous les *chemins d'accès* du routeur et seront exécutées/résolues pour chaque requête qui leur est faite.

/// tip | Astuce

une `response_class` avec un media type JSON (`application/json`), comme c'est le cas avec `JSONResponse`, les données que vous renvoyez seront automatiquement converties (et filtrées) avec tout `response_model` Pydantic que vous avez déclaré dans le décorateur de *chemin d'accès*. Mais les données ne seront pas sérialisées en octets JSON avec Pydantic, elles seront converties avec le `jsonable_encoder` puis passées à la classe `JSONResponse`, qui les sérialisera en octets en utilisant la bibliothèque...

Et chaque fois que vous renverrez ces données, même si la source contenait des doublons, elles seront renvoyées sous la forme d'un set d'éléments uniques.

Elles seront également annotées / documentées en conséquence.

## Modèles imbriqués { #nested-models }

Chaque attribut d'un modèle Pydantic a un type.

# Tâches d'arrière-plan { #background-tasks }

Vous pouvez définir des tâches d'arrière-plan qui seront exécutées après avoir retourné une réponse.

Ceci est utile pour les opérations qui doivent avoir lieu après une requête, mais où le client n'a pas réellement besoin d'attendre que l'opération soit terminée pour recevoir une réponse.

Cela comprend, par exemple :

* Les notifications par email envoyées après l'exécution d'une action :