## Origine { #origin }

Une origine est la combinaison du protocole (`http`, `https`), du domaine (`myapp.com`, `localhost`, `localhost.tiangolo.com`) et du port (`80`, `443`, `8080`).

Ainsi, toutes celles-ci sont des origines différentes :

* `http://localhost`
* `https://localhost`
* `http://localhost:8080`

Après avoir testé plusieurs alternatives, j'ai décidé que j'allais utiliser [**Pydantic**](https://docs.pydantic.dev/) pour ses avantages.

J'y ai ensuite contribué, pour le rendre entièrement compatible avec JSON Schema, pour supporter différentes manières de définir les déclarations de contraintes, et pour améliorer le support des éditeurs (vérifications de type, autocomplétion) sur la base des tests effectués dans plusieurs éditeurs.

Alors, quel est le problème d’installer des packages dans l’environnement Python global ?

À un moment donné, vous finirez probablement par écrire de nombreux programmes différents qui dépendent de packages différents. Et certains de ces projets sur lesquels vous travaillez dépendront de versions différentes du même package. 😱

Dans ce cas, elle nécessite le scope `me` (elle pourrait en exiger plusieurs).

/// note | Remarque

Vous n’avez pas nécessairement besoin d’ajouter des scopes différents à différents endroits.

Nous le faisons ici pour montrer comment **FastAPI** gère des scopes déclarés à différents niveaux.

///

{* ../../docs_src/security/tutorial005_an_py310.py hl[5,141,172] *}

/// info | Détails techniques

Et il existe beaucoup d'autres images pour différentes choses comme des bases de données, par exemple :

* [PostgreSQL](https://hub.docker.com/_/postgres)
* [MySQL](https://hub.docker.com/_/mysql)
* [MongoDB](https://hub.docker.com/_/mongo)
* [Redis](https://hub.docker.com/_/redis), etc.

Ici, **FastAPI** ne s'y trompera pas car vous utilisez `Depends`.

///

/// check | Vérifications

La manière dont ce système de dépendances est conçu nous permet d'avoir différentes dépendances (différents « dependables ») qui retournent toutes un modèle `User`.

Nous ne sommes pas limités à une seule dépendance pouvant retourner ce type de données.

///

## Autres modèles { #other-models }

### `response_model` ou type de retour { #response-model-or-return-type }

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

Toutes les conversions de données, validations, documentation, etc., fonctionneront comme d'habitude.

De cette façon, nous pouvons ne déclarer que les différences entre les modèles (avec `password` en clair, avec `hashed_password` et sans mot de passe) :

{* ../../docs_src/extra_models/tutorial002_py310.py hl[7,13:14,17:18,21:22] *}

## `Union` ou `anyOf` { #union-or-anyof }

> Vous devez nettoyer une grande et sale maison.

*Oui, c'est toute l'histoire*.

---

Il n'y a plus d'attente 🕙 nulle part, juste beaucoup de travail à effectuer, dans différentes pièces de la maison.

Vous pourriez diviser en différentes sections comme avec les burgers, d'abord le salon, puis la cuisine, etc. Mais vous n'attendez 🕙 rien, vous ne faites que nettoyer et nettoyer, la séparation en sections ne changerait rien au final.

Toutes les dépendances que nous avons vues étaient des fonctions ou des classes fixes.

Mais il peut y avoir des cas où vous souhaitez pouvoir définir des paramètres sur la dépendance, sans devoir déclarer de nombreuses fonctions ou classes différentes.

Imaginons que nous voulions avoir une dépendance qui vérifie si le paramètre de requête `q` contient un contenu fixe.

Mais nous voulons pouvoir paramétrer ce contenu fixe.