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.

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

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

# Response-Statuscode { #response-status-code }

Genauso wie Sie ein Responsemodell angeben können, können Sie auch den HTTP-Statuscode für die <abbr title="Response – Antwort: Daten, die der Server zum anfragenden Client zurücksendet">Response</abbr> mit dem Parameter `status_code` in jeder der *Pfadoperationen* deklarieren:

* `@app.get()`
* `@app.post()`
* `@app.put()`
* `@app.delete()`
* usw.

### Das OpenAPI-Schema ändern { #modify-the-openapi-schema }

Jetzt können Sie die ReDoc-Erweiterung hinzufügen und dem `info`-„Objekt“ im OpenAPI-Schema ein benutzerdefiniertes `x-logo` hinzufügen:

{* ../../docs_src/extending_openapi/tutorial001_py39.py hl[22:24] *}

### Zwischenspeichern des OpenAPI-Schemas { #cache-the-openapi-schema }

///

## Nachrichten erwarten und Nachrichten senden { #await-for-messages-and-send-messages }

In Ihrer WebSocket-Route können Sie Nachrichten `await`en und Nachrichten senden.

{* ../../docs_src/websockets/tutorial001_py39.py hl[48:52] *}

Sie können Binär-, Text- und JSON-Daten empfangen und senden.

## Es ausprobieren { #try-it }

Wenn Ihre Datei `main.py` heißt, führen Sie Ihre Anwendung so aus:

### Dependency Injection { #dependency-injection }

FastAPI enthält ein extrem einfach zu verwendendes, aber extrem mächtiges <abbr title='auch bekannt als „Komponenten“, „Resourcen“, „Dienste“, „Dienstanbieter“'><strong>Dependency Injection</strong></abbr> System.

# GraphQL { #graphql }

Da **FastAPI** auf dem **ASGI**-Standard basiert, ist es sehr einfach, jede **GraphQL**-Bibliothek zu integrieren, die auch mit ASGI kompatibel ist.

Sie können normale FastAPI-*Pfadoperationen* mit GraphQL in derselben Anwendung kombinieren.

/// tip | Tipp

**GraphQL** löst einige sehr spezifische Anwendungsfälle.

Es hat **Vorteile** und **Nachteile** im Vergleich zu gängigen **Web-APIs**.