L'utilisation d'`async` et `await` est relativement nouvelle dans ce langage.

Mais cela rend la programmation asynchrone bien plus simple.

Cette même syntaxe (ou presque) a aussi été incluse récemment dans les versions modernes de JavaScript (dans les navigateurs et NodeJS).

Mais avant ça, gérer du code asynchrone était bien plus complexe et difficile.

* L'élément auquel le client tentait d'accéder n'existe pas.
* etc.

Dans ces cas, vous retournez normalement un **code d'état HTTP** dans la plage de **400** (de 400 à 499).

C'est similaire aux codes d'état HTTP 200 (de 200 à 299). Ces codes « 200 » signifient que, d'une certaine manière, la requête a été un « succès ».

Les codes d'état dans la plage des 400 signifient qu'il y a eu une erreur côté client.

# Utiliser des middlewares avancés { #advanced-middleware }

Dans le tutoriel principal, vous avez vu comment ajouter des [middlewares personnalisés](../tutorial/middleware.md) à votre application.

Vous avez également vu comment gérer [CORS avec le `CORSMiddleware`](../tutorial/cors.md).

Dans cette section, nous allons voir comment utiliser d'autres middlewares.

## Ajouter des middlewares ASGI { #adding-asgi-middlewares }

### Modèle de sortie dans les documents { #model-for-output-in-docs }

Vous pouvez également vérifier le modèle de sortie dans les documents, **à la fois** `name` et `description` sont marqués comme **requis** avec un **astérisque rouge** :

<div class="screenshot">
<img src="/img/tutorial/separate-openapi-schemas/image03.png">
</div>

### Modèle pour l'entrée et la sortie dans les documents { #model-for-input-and-output-in-docs }

## Consulter les documents { #check-the-docs }

Vous pouvez voir les paramètres de requête dans l'interface des documents à `/docs` :

<div class="screenshot">
<img src="/img/tutorial/query-param-models/image01.png">
</div>

## Interdire des paramètres de requête supplémentaires { #forbid-extra-query-parameters }

En tenant compte de ces concepts, vous serez en mesure **d'évaluer et de concevoir** la meilleure façon de déployer **vos propres API**.

Dans les chapitres suivants, je vous donnerai des **recettes concrètes** pour déployer des applications FastAPI.

Il y a un chapitre entier dans la documentation à ce sujet, vous pouvez le lire dans [Réponses supplémentaires dans OpenAPI](additional-responses.md).

## OpenAPI supplémentaire { #openapi-extra }

Lorsque vous déclarez un chemin d’accès dans votre application, **FastAPI** génère automatiquement les métadonnées pertinentes à propos de ce chemin d’accès à inclure dans le schéma OpenAPI.

/// note | Détails techniques

`status_code` peut aussi recevoir un `IntEnum`, comme le [`http.HTTPStatus`](https://docs.python.org/3/library/http.html#http.HTTPStatus) de Python.

///

Il va :

* Renvoyer ce code d'état dans la réponse.
* Le documenter comme tel dans le schéma OpenAPI (et donc dans les interfaces utilisateur) :

<img src="/img/tutorial/response-status-code/image01.png">

/// note | Remarque

/// tip | Astuce

Si vous souhaitez appeler des fonctions `async` dans vos tests en dehors de l’envoi de requêtes à votre application FastAPI (par exemple des fonctions de base de données asynchrones), consultez les [Tests asynchrones](../advanced/async-tests.md) dans le tutoriel avancé.

///

## Séparer les tests { #separating-tests }

Dans une application réelle, vous auriez probablement vos tests dans un fichier différent.