le système de conteneurs distribués avec l'**équilibreur de charge** **distribuera les requêtes** à chacun des conteneurs exécutant votre application **à tour de rôle**. Ainsi, chaque requête pourrait être traitée par l'un des multiples **conteneurs répliqués** exécutant votre application.

Et normalement cet **équilibreur de charge** pourra gérer des requêtes qui vont vers *d'autres* applications dans votre cluster (par ex. vers un autre domaine, ou sous un autre préfixe de chemin d'URL),...

* `dependencies` : ils ont tous besoin de la dépendance `X-Token` que nous avons créée.

Donc, au lieu d'ajouter tout cela à chaque *chemin d'accès*, nous pouvons l'ajouter au `APIRouter`.

{* ../../docs_src/bigger_applications/app_an_py310/routers/items.py hl[5:10,16,21] title["app/routers/items.py"] *}

Comme le chemin de chaque *chemin d'accès* doit commencer par `/`, comme dans :

```Python hl_lines="1"
@router.get("/{item_id}")

Vous pouvez définir le `status_code` (HTTP) à utiliser dans la réponse de votre *chemin d'accès*.

Vous pouvez passer directement le code `int`, comme `404`.

Mais si vous ne vous souvenez pas à quoi correspond chaque code numérique, vous pouvez utiliser les constantes abrégées dans `status` :

{* ../../docs_src/path_operation_configuration/tutorial001_py310.py hl[1,15] *}

La solution aux problèmes posés par le fait d’avoir tous les packages dans l’environnement global est d’utiliser un environnement virtuel pour chaque projet sur lequel vous travaillez.

Un environnement virtuel est un répertoire, très similaire à celui global, où vous pouvez installer les packages pour un projet.

De cette manière, chaque projet aura son propre environnement virtuel (répertoire `.venv`) avec ses propres packages.

```mermaid
flowchart TB

/// tip | Astuce

L’élément important et « magique » ici est que `get_current_user` aura une liste différente de `scopes` à vérifier pour chaque *chemin d’accès*.

Tout dépend des `scopes` déclarés dans chaque *chemin d’accès* et chaque dépendance dans l’arbre de dépendances pour ce *chemin d’accès* spécifique.

///

## Détails supplémentaires sur `SecurityScopes` { #more-details-about-securityscopes }

* `routes` : Une liste de routes ; chacune correspond à un *chemin d'accès* enregistré. Elles sont extraites de `app.routes`.

/// info

Le paramètre `summary` est disponible à partir d'OpenAPI 3.1.0, pris en charge par FastAPI 0.99.0 et versions ultérieures.

///

## Remplacer les valeurs par défaut { #overriding-the-defaults }

Cela signifie :

* La variable `prices` est un `dict` :
    * Les clés de ce `dict` sont de type `str` (disons, le nom de chaque article).
    * Les valeurs de ce `dict` sont de type `float` (disons, le prix de chaque article).

#### Union { #union }

Vous pouvez déclarer qu'une variable peut être **plusieurs types**, par exemple, un `int` ou un `str`.

/// info | Info

Ajouté dans FastAPI 0.135.0.

///

## 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.

Vous pouvez passer à vos décorateurs de *chemin d'accès* un paramètre `responses`.

Il prend comme valeur un `dict` dont les clés sont des codes HTTP pour chaque réponse, comme `200`, et la valeur de ces clés sont d'autres `dict` avec des informations pour chacun d'eux.

Chacun de ces `dict` de réponse peut avoir une clé `model`, contenant un modèle Pydantic, tout comme `response_model`.

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.