Cela comprend, par exemple :

* Les notifications par email envoyées après l'exécution d'une action :
    * Étant donné que se connecter à un serveur et envoyer un email a tendance à être « lent » (plusieurs secondes), vous pouvez retourner la réponse directement et envoyer la notification en arrière-plan.
* Traiter des données :

    Note over App: Keeps producing...
    Note over Client: Keeps consuming...
```

Cela peut même être un flux infini, où vous continuez à envoyer des données.

## JSON Lines { #json-lines }

Dans ces cas, il est courant d'envoyer des « JSON Lines », qui est un format où vous envoyez un objet JSON par ligne.

Une réponse aurait un type de contenu `application/jsonl` (au lieu de `application/json`) et le corps ressemblerait à ceci :

///

## Attendre des messages et envoyer des messages { #await-for-messages-and-send-messages }

Dans votre route WebSocket, vous pouvez `await` des messages et envoyer des messages.

{* ../../docs_src/websockets_/tutorial001_py310.py hl[48:52] *}

Vous pouvez recevoir et envoyer des données binaires, texte et JSON.

## Essayer { #try-it }

## Données brutes { #raw-data }

Si vous devez envoyer des données **sans** encodage JSON, utilisez `raw_data` au lieu de `data`.

C’est utile pour envoyer du texte préformaté, des lignes de log, ou des valeurs <dfn title="Une valeur utilisée pour indiquer une condition ou un état particulier">« sentinelle »</dfn> spéciales comme `[DONE]`.

* Elle s’exécute sans aucune authentification, il n’y a pas à envoyer d’informations d’authentification.
* Le navigateur pense qu’il n’envoie pas de JSON (faute d’en-tête `Content-Type`).

Le site malveillant pourrait alors amener l’agent IA local à envoyer des messages en colère à l’ancien patron de l’utilisateur ... ou pire. 😅

## Internet ouvert { #open-internet }

Si votre application doit recevoir et envoyer des données JSON, mais que vous devez y inclure des données binaires, vous pouvez les encoder en base64.

## Base64 vs fichiers { #base64-vs-files }

Quand vous avez besoin d'envoyer de la donnée depuis un client (comme un navigateur) vers votre API, vous l'envoyez en tant que **corps de requête**.

Le corps d'une **requête** est de la donnée envoyée par le client à votre API. Le corps d'une **réponse** est la donnée envoyée par votre API au client.

Et vos utilisateurs définissent aussi, d'une manière ou d'une autre (par exemple dans un tableau de bord Web), l'URL à laquelle votre application doit envoyer ces requêtes.

Toute la logique de gestion des URL des webhooks et le code qui envoie effectivement ces requêtes vous incombent. Vous l'implémentez comme vous le souhaitez dans votre propre code.

```console
$ pip install python-multipart
```

Cela est dû au fait que **OAuth2** utilise des « form data » pour envoyer le `username` et le `password`.

///

Exécutez l'exemple avec :

<div class="termy">

```console
$ fastapi dev

│   └── test_main.py
```

Supposons que désormais le fichier `main.py` avec votre application **FastAPI** contienne d’autres **chemins d’accès**.

Il a une opération `GET` qui pourrait renvoyer une erreur.

Il a une opération `POST` qui pourrait renvoyer plusieurs erreurs.

Les deux chemins d’accès requièrent un en-tête `X-Token`.

{* ../../docs_src/app_testing/app_b_an_py310/main.py *}