Wir könnten es besser machen.

Wir können ein `UserBase`-Modell deklarieren, das als Basis für unsere anderen Modelle dient. Und dann können wir Unterklassen dieses Modells erstellen, die seine Attribute (Typdeklarationen, Validierung usw.) erben.

Die ganze Datenkonvertierung, -validierung, -dokumentation usw. wird immer noch wie gewohnt funktionieren.

In diesen Fällen können Sie einen `Response`-Parameter verwenden.

## Einen `Response`-Parameter verwenden { #use-a-response-parameter }

Sie können einen Parameter vom Typ `Response` in Ihrer *Pfadoperation-Funktion* deklarieren (wie Sie es auch für Cookies und Header tun können).

Aber dann haben wir ein `dict` im Parameter `commons` der *Pfadoperation-Funktion*.

Und wir wissen, dass Editoren nicht viel Unterstützung (wie etwa Code-Vervollständigung) für `dict`s bieten können, weil sie ihre Schlüssel- und Werttypen nicht kennen.

Das können wir besser machen ...

## Was macht eine Abhängigkeit aus { #what-makes-a-dependency }

Bisher haben Sie Abhängigkeiten gesehen, die als Funktionen deklariert wurden.

Sie können jedoch direkt eine `JSONResponse` von Ihren *Pfadoperationen* zurückgeben.

Das kann beispielsweise nützlich sein, um benutzerdefinierte Header oder Cookies zurückzugeben.

## Eine `Response` zurückgeben { #return-a-response }

Tatsächlich können Sie jede `Response` oder jede Unterklasse davon zurückgeben.

/// tip | Tipp

Schauen wir uns an, wie wir das machen können.

## pytest.mark.anyio { #pytest-mark-anyio }

Wenn wir in unseren Tests asynchrone Funktionen aufrufen möchten, müssen unsere Testfunktionen asynchron sein. AnyIO stellt hierfür ein nettes Plugin zur Verfügung, mit dem wir festlegen können, dass einige Testfunktionen asynchron aufgerufen werden sollen.

## HTTPX { #httpx }

Da Abhängigkeiten auch von **FastAPI** aufgerufen werden (so wie Ihre *Pfadoperation-Funktionen*), gelten beim Definieren Ihrer Funktionen die gleichen Regeln.

Sie können `async def` oder einfach `def` verwenden.

Und Sie können Abhängigkeiten mit `async def` innerhalb normaler `def`-*Pfadoperation-Funktionen* oder `def`-Abhängigkeiten innerhalb von `async def`-*Pfadoperation-Funktionen*, usw. deklarieren.

# Zusätzliche Datentypen { #extra-data-types }

Bisher haben Sie gängige Datentypen verwendet, wie zum Beispiel:

* `int`
* `float`
* `str`
* `bool`

Sie können aber auch komplexere Datentypen verwenden.

Und Sie haben immer noch dieselbe Funktionalität wie bisher gesehen:

* Großartige Editor-Unterstützung.
* Datenkonvertierung bei eingehenden <abbr title="Request – Anfrage: Daten, die der Client zum Server sendet">Requests</abbr>.

# Bedingte OpenAPI { #conditional-openapi }

Bei Bedarf können Sie OpenAPI mithilfe von Einstellungen und Umgebungsvariablen abhängig von der Umgebung bedingt konfigurieren und sogar vollständig deaktivieren.

## Über Sicherheit, APIs und Dokumentation { #about-security-apis-and-docs }

Das Verstecken Ihrer Dokumentationsoberflächen in der Produktion *sollte nicht* die Methode sein, Ihre API zu schützen.

Tatsächlich gibt es in einigen Fällen sogar **zwei JSON-Schemas** in OpenAPI für dasselbe Pydantic-Modell, für Eingabe und Ausgabe, je nachdem, ob sie **Defaultwerte** haben.

Sehen wir uns an, wie das funktioniert und wie Sie es bei Bedarf ändern können.

## Pydantic-Modelle für Eingabe und Ausgabe { #pydantic-models-for-input-and-output }

Nehmen wir an, Sie haben ein Pydantic-Modell mit Defaultwerten wie dieses:

## Nur-JavaScript-Einstellungen { #javascript-only-settings }

Die Swagger-Oberfläche erlaubt, dass andere Konfigurationen auch **Nur-JavaScript**-Objekte sein können (z. B. JavaScript-Funktionen).