Comment fonctionne le cycle de vie d'une requête dans FastAPI ?

Question

IT Interview Practice · Accepted Answer

FastAPI s'exécute sur **ASGI**, donc une requête traverse un pipeline asynchrone : le serveur ASGI l'accepte, le middleware l'enveloppe, le router associe un path, **les dependencies sont résolues**, votre path operation s'exécute, et la valeur de retour est sérialisée dans la response.

## Les étapes

```
uvicorn (ASGI server)
   │  scope + receive/send
   ▼
ASGI / Starlette middleware  ── (CORS, GZip, personnalisé)
   ▼
Routing  ── associe method + path → path operation
   ▼
Dependencies (Depends)  ── résout sous-deps, security, yield-setup
   ▼
Path operation function  ── votre handler s'exécute
   ▼
Response model  ── valide + sérialise en JSON
   ▼
Background tasks  ── s'exécutent après l'envoi de la response
   ▼
Response ──▶ client
```

1. **ASGI server** (uvicorn/hypercorn) accepte la connexion et transmet un `scope` ainsi que les callables `receive`/`send` à l'application.
2. **Middleware** s'exécute de l'extérieur vers l'intérieur à l'aller et de l'intérieur vers l'extérieur au retour (`BaseHTTPMiddleware` ou middleware ASGI pur). CORS, GZip et la mesure de temps personnalisée résident ici.
3. **Routing** associe la méthode HTTP + le path à une path operation ; les paramètres path/query/body sont extraits et validés par **Pydantic**.
4. **Dependency injection** — `Depends(...)` résout chaque dependency (session DB, utilisateur courant, settings), avec mise en cache au sein de la requête. Une dependency avec `yield` exécute le setup avant et le teardown après le handler.
5. **Path operation** — votre `async def` (ou `def`, exécuté dans un threadpool) exécute la logique métier.
6. **Response** — la valeur de retour est convertie vers le `response_model` déclaré, validée et sérialisée en JSON ; le status code et les headers sont appliqués.
7. **Background tasks** enregistrées via `BackgroundTasks` s'exécutent *après* l'envoi de la response.

```python
from fastapi import FastAPI, Depends, Request

app = FastAPI()

@app.middleware("http")
async def timing(request: Request, call_next):   # 2. middleware
    response = await call_next(request)
    response.headers["X-Time"] = "..."
    return response

async def get_db():                               # 4. dependency (yield)
    db = Session()
    try:
        yield db
    finally:
        db.close()

@app.get("/items/{id}")                           # 3. routing
async def read_item(id: int, db=Depends(get_db)): # 5. handler
    return db.get(Item, id)                        # 6. sérialisé via response_model
```

Les exceptions sont interceptées par des **exception handlers** (`@app.exception_handler(...)` / `HTTPException`), qui les convertissent en responses au lieu de faire planter la requête.

## Pourquoi c'est important

Le cycle de vie de la requête est l'endroit où les fonctionnalités phares de FastAPI se produisent réellement : l'I/O asynchrone, la validation Pydantic et la dependency injection se greffent tous sur des étapes précises. Connaître l'ordre — middleware, puis routing, puis dependencies, puis handler, puis serialization — vous permet de placer la logique transversale au bon endroit (auth en tant que dependency, mesure de temps en tant que middleware, nettoyage dans une dependency `yield`), de déboguer pourquoi une erreur de validation ou d'auth se déclenche avant votre code, et d'éviter de bloquer l'event loop à l'intérieur d'un handler async.

Les étapes

Pourquoi c'est important

Questions connexes