- the request body: le corps de la requête
- the response body: le corps de la réponse

- path operation: chemin d'accès
- path operations (plural): chemins d'accès
- path operation function: fonction de chemin d'accès
- path operation decorator: décorateur de chemin d'accès

- path parameter: paramètre de chemin
- query parameter: paramètre de requête

- the `Request`: `Request` (keep as code identifier)

### Étape 3 : créer un « chemin d’accès » { #step-3-create-a-path-operation }

#### Chemin { #path }

« Chemin » fait ici référence à la dernière partie de l’URL à partir du premier `/`.

Donc, dans une URL telle que :

```
https://example.com/items/foo
```

... le chemin serait :

```
/items/foo
```

/// info

## Dépendances pour des groupes de *chemins d'accès* { #dependencies-for-groups-of-path-operations }

Vous avez des *chemins d'accès* pour :

* `/items/`
* `/items/{item_id}`

C'est exactement la même structure que pour `app/routers/users.py`.

Mais nous voulons être plus malins et simplifier un peu le code.

Nous savons que tous les *chemins d'accès* de ce module ont les mêmes éléments :

* Préfixe de chemin `prefix` : `/items`.
* `tags` : (un seul tag : `items`).

# Gérer les dépendances dans les décorateurs de chemins d'accès { #dependencies-in-path-operation-decorators }

Dans certains cas, vous n'avez pas vraiment besoin de la valeur de retour d'une dépendance dans votre *fonction de chemin d'accès*.

Ou la dépendance ne retourne aucune valeur.

Mais vous avez quand même besoin qu'elle soit exécutée/résolue.

# Configurer les chemins d'accès { #path-operation-configuration }

Vous pouvez passer plusieurs paramètres à votre *décorateur de chemin d'accès* pour le configurer.

/// warning | Alertes

Notez que ces paramètres sont passés directement au *décorateur de chemin d'accès*, et non à votre *fonction de chemin d'accès*.

///

## Définir le code d'état de la réponse { #response-status-code }

Pour ajouter des étiquettes à vos *chemins d'accès* et les regrouper dans l'interface utilisateur de la documentation, lisez les documents [Tutoriel - Configurations de chemin d'accès - Tags](../tutorial/path-operation-configuration.md#tags).

## Résumé et description de la documentation - OpenAPI { #documentation-summary-and-description-openapi }

```

... c’est parce que le générateur de client utilise l’**operation ID** interne OpenAPI pour chaque *chemin d'accès*.

OpenAPI exige que chaque operation ID soit unique parmi tous les *chemins d'accès*, donc FastAPI utilise le **nom de la fonction**, le **chemin**, et la **méthode/opération HTTP** pour générer cet operation ID, car de cette façon il peut s’assurer que les operation IDs sont uniques.

C’est simplement une fonction qui peut prendre tous les mêmes paramètres qu’une fonction de chemin d’accès peut prendre :

{* ../../docs_src/dependencies/tutorial001_an_py310.py hl[8:9] *}

C’est tout.

**2 lignes**.

Et elle a la même forme et structure que toutes vos fonctions de chemins d’accès.

Vous pouvez la considérer comme une fonction de chemin d’accès sans le « décorateur » (sans le `@app.get("/some-path")`).

Notez qu'avec les webhooks, vous ne déclarez pas réellement un chemin (comme `/items/`), le texte que vous y passez est simplement un identifiant du webhook (le nom de l'événement). Par exemple, dans `@app.webhooks.post("new-subscription")`, le nom du webhook est `new-subscription`.

C'est parce qu'on s'attend à ce que vos utilisateurs définissent, par un autre moyen (par exemple un tableau de bord Web), le véritable chemin d'URL où ils souhaitent recevoir la requête de webhook.