* **`400`** und darüber stehen für „Client error“-Responses („Client-Fehler“). Auch diese verwenden Sie am häufigsten.
    * Ein Beispiel ist `404`, für eine „Not Found“-Response („Nicht gefunden“).
    * Für allgemeine Fehler beim Client können Sie einfach `400` verwenden.

Der `root_path` wird verwendet, um diese speziellen Fälle zu handhaben.

Und er wird auch intern beim Mounten von Unteranwendungen verwendet.

## Proxy mit einem abgetrennten Pfadpräfix

In diesen Fällen könnten mehrere dieser Entitäten die gleiche ID haben, sagen wir `foo` (ein Benutzer `foo`, ein Auto `foo` und ein Blog-Beitrag `foo`).

Deshalb, um ID-Kollisionen zu vermeiden, könnten Sie beim Erstellen des JWT-Tokens für den Benutzer, dem Wert des `sub`-Schlüssels ein Präfix, z. B. `username:` voranstellen. In diesem Beispiel hätte der Wert von `sub` also auch `username:johndoe` sein können.

Das ist die Grundidee. Aber Sie möchten sich wahrscheinlich um einige zusätzliche Dinge kümmern, wie zum Beispiel:

* Sicherheit – HTTPS
* Beim Hochfahren ausführen
* Neustarts
* Replikation (die Anzahl der laufenden Prozesse)
* Arbeitsspeicher
* Schritte vor dem Start

Wir verifizieren, dass wir einen `username` erhalten, und extrahieren die Scopes.

Und dann validieren wir diese Daten mit dem Pydantic-Modell (wobei wir die `ValidationError`-Exception abfangen), und wenn wir beim Lesen des JWT-Tokens oder beim Validieren der Daten mit Pydantic einen Fehler erhalten, lösen wir die zuvor erstellte `HTTPException` aus.

Dazu aktualisieren wir das Pydantic-Modell `TokenData` mit einem neuen Attribut `scopes`.

# Header-Parameter

So wie `Query`-, `Path`-, und `Cookie`-Parameter können Sie auch <abbr title='Header – Kopfzeilen, Header, Header-Felder: Schlüssel-Wert-Metadaten, die vom Client beim Request, und vom Server bei der Response gesendet werden'>Header</abbr>-Parameter definieren.

## `Header` importieren

Importieren Sie zuerst `Header`:

=== "Python 3.10+"

    ```Python hl_lines="3"
    {!> ../../../docs_src/header_params/tutorial001_an_py310.py!}

Tatsächlich sind diese Codeblöcke nicht Teil des Markdowns, sondern Python-Dateien im Verzeichnis `./docs_src/`.

Und diese Python-Dateien werden beim Generieren der Site in die Dokumentation eingefügt.

### Dokumentation für Tests

Tatsächlich arbeiten die meisten Tests mit den Beispielquelldateien in der Dokumentation.

Dadurch wird sichergestellt, dass:

Und Sie möchten eine Möglichkeit haben, dass sich das Frontend mithilfe eines **Benutzernamens** und eines **Passworts** beim Backend authentisieren kann.

Wir können **OAuth2** verwenden, um das mit **FastAPI** zu erstellen.

# Extramodelle

Fahren wir beim letzten Beispiel fort. Es gibt normalerweise mehrere zusammengehörende Modelle.

Insbesondere Benutzermodelle, denn:

* Das **hereinkommende Modell** sollte ein Passwort haben können.
* Das **herausgehende Modell** sollte kein Passwort haben.

* **WebSocket**-Unterstützung.
* Hintergrundaufgaben im selben Prozess.
* Ereignisse beim Starten und Herunterfahren.
* Testclient baut auf HTTPX auf.
* **CORS**, GZip, statische Dateien, Responses streamen.
* **Sitzungs- und Cookie**-Unterstützung.
* 100 % Testabdeckung.
* 100 % Typen annotierte Codebasis.