* Le tout **géré automatiquement** par le framework.
* Toutes les dépendances peuvent exiger des données des requêtes et **augmenter les contraintes du chemin d'accès** ainsi que la documentation automatique.
* **Validation automatique** même pour les paramètres de *chemin d'accès* définis dans les dépendances.
* Prise en charge des systèmes d'authentification d'utilisateurs complexes, des **connexions de base de données**, etc.

Si vous allez dans **l'interface de la documentation de l'API** à `/docs`, vous pourrez voir la **documentation** des cookies pour vos *chemins d'accès*.

## Récapitulatif { #recap }

Vous pouvez ajouter plusieurs paramètres du corps de la requête à votre fonction de chemin d'accès, même si une requête ne peut avoir qu'un seul corps de la requête.

Mais **FastAPI** s'en chargera, vous fournira les bonnes données dans votre fonction, et validera et documentera le schéma correct dans le chemin d'accès.

Vous pouvez également déclarer des valeurs singulières à recevoir dans le corps de la requête.

* `Depends`
* `Security`
* `Cookie`
* `Header`
* `Path`
* `Query`

Ils fonctionnent de la même manière que pour les autres endpoints/*chemins d'accès* FastAPI :

{* ../../docs_src/websockets_/tutorial002_an_py310.py hl[68:69,82] *}

/// info

À ce stade, vous avez le(s) *chemin(s) d'accès de callback* nécessaire(s) (celui/ceux que la *personne développeuse externe* doit implémenter dans l’*API externe*) dans le routeur de callback que vous avez créé ci-dessus.

Utilisez maintenant le paramètre `callbacks` dans *le décorateur de chemin d'accès de votre API* pour passer l’attribut `.routes` (qui est en fait juste une `list` de routes/*chemins d'accès*) depuis ce routeur de callback :

* « function » : démarrer la dépendance avant la *fonction de chemin d'accès* qui gère la requête, terminer la dépendance après la fin de la *fonction de chemin d'accès*, mais **avant** que la réponse ne soit renvoyée au client. Ainsi, la fonction de dépendance sera exécutée **autour** de la *fonction de chemin d'accès*.

Dans ces cas, vous pouvez utiliser le paramètre `response_model` du *décorateur de chemin d'accès* au lieu du type de retour.

Vous pouvez utiliser le paramètre `response_model` dans n'importe lequel des *chemins d'accès* :

* `@app.get()`
* `@app.post()`
* `@app.put()`
* `@app.delete()`
* etc.

```
.
├── Dockerfile
├── main.py
└── requirements.txt
```

Vous n'auriez alors qu'à changer les chemins correspondants pour copier le fichier dans le `Dockerfile` :

```{ .dockerfile .annotate hl_lines="10  13" }
FROM python:3.14

WORKDIR /code

COPY ./requirements.txt /code/requirements.txt

Et malgré cela, vous ne voudrez probablement pas que l'application reste à l'arrêt parce qu'il y a eu une erreur à un endroit ; vous voudrez probablement qu'elle **continue de tourner**, au moins pour les *chemins d'accès* qui ne sont pas cassés.

### Redémarrer après un plantage { #restart-after-crash }

```

Vous avez déjà créé une API qui :

* Reçoit des requêtes HTTP sur les _chemins_ `/` et `/items/{item_id}`.
* Les deux _chemins_ acceptent des opérations `GET` (également connues sous le nom de _méthodes_ HTTP).
* Le _chemin_ `/items/{item_id}` a un _paramètre de chemin_ `item_id` qui doit être un `int`.
* Le _chemin_ `/items/{item_id}` a un _paramètre de requête_ optionnel `q` de type `str`.