Wenn Sie in ihrer Funktion Parameter deklarieren, die nicht Teil der Pfad-Parameter sind, dann werden diese automatisch als „Query“-Parameter interpretiert.

{* ../../docs_src/query_params/tutorial001.py hl[9] *}

Query-Parameter (Deutsch: Abfrage-Parameter) sind die Schlüssel-Wert-Paare, die nach dem `?` in einer URL aufgelistet sind, getrennt durch `&`-Zeichen.

Zum Beispiel sind in der URL:

```
http://127.0.0.1:8000/items/?skip=0&limit=10
```

## Zusätzliche Response mit `model`

Sie können Ihren *Pfadoperation-Dekoratoren* einen Parameter `responses` übergeben.

Der nimmt ein `dict` entgegen, die Schlüssel sind Statuscodes für jede Response, wie etwa `200`, und die Werte sind andere `dict`s mit den Informationen für jede Response.

Jedes dieser Response-`dict`s kann einen Schlüssel `model` haben, welcher ein Pydantic-Modell enthält, genau wie `response_model`.

# How-To – Rezepte

Hier finden Sie verschiedene Rezepte und „How-To“-Anleitungen zu **verschiedenen Themen**.

Die meisten dieser Ideen sind mehr oder weniger **unabhängig**, und in den meisten Fällen müssen Sie diese nur studieren, wenn sie direkt auf **Ihr Projekt** anwendbar sind.

Wenn etwas für Ihr Projekt interessant und nützlich erscheint, lesen Sie es, andernfalls überspringen Sie es einfach.

/// tip | Tipp

* Großartige Editor-Unterstützung.
* Datenkonvertierung bei eingehenden Requests.
* Datenkonvertierung für Response-Daten.
* Datenvalidierung.
* Automatische Annotation und Dokumentation.

## Andere Datentypen

Hier sind einige der zusätzlichen Datentypen, die Sie verwenden können:

* `UUID`:
    * Ein standardmäßiger „universell eindeutiger Bezeichner“ („Universally Unique Identifier“), der in vielen Datenbanken und Systemen als ID üblich ist.

## `jsonable_encoder` verwenden

Stellen wir uns vor, Sie haben eine Datenbank `fake_db`, die nur JSON-kompatible Daten entgegennimmt.

Sie akzeptiert zum Beispiel keine `datetime`-Objekte, da die nicht kompatibel mit JSON sind.

Ein `datetime`-Objekt müsste also in einen `str` umgewandelt werden, der die Daten im <a href="https://en.wikipedia.org/wiki/ISO_8601" class="external-link" target="_blank">ISO-Format</a> enthält.

///

/// check

Die Art und Weise, wie dieses System von Abhängigkeiten konzipiert ist, ermöglicht es uns, verschiedene Abhängigkeiten (verschiedene „Dependables“) zu haben, die alle ein `User`-Modell zurückgeben.

Wir sind nicht darauf beschränkt, nur eine Abhängigkeit zu haben, die diesen Typ von Daten zurückgeben kann.

///

## Andere Modelle

### Ausgabemodell in der Dokumentation

Sie können das Ausgabemodell auch in der Dokumentation überprüfen. **Sowohl** `name` **als auch** `description` sind mit einem **roten Sternchen** als **erforderlich** markiert:

<div class="screenshot">
<img src="/img/tutorial/separate-openapi-schemas/image03.png">
</div>

### Eingabe- und Ausgabemodell in der Dokumentation

`Body` gibt auch Instanzen einer Unterklasse von `FieldInfo` zurück. Und später werden Sie andere sehen, die Unterklassen der `Body`-Klasse sind.

Denken Sie daran, dass `Query`, `Path` und andere von `fastapi` tatsächlich Funktionen sind, die spezielle Klassen zurückgeben.

///

/// tip | Tipp

In den nächsten Abschnitten sehen Sie weitere Optionen, Konfigurationen und zusätzliche Funktionen.

/// tip | Tipp

Die nächsten Abschnitte sind **nicht unbedingt „fortgeschritten“**.

Und es ist möglich, dass für Ihren Anwendungsfall die Lösung in einem davon liegt.

///

## Lesen Sie zuerst das Tutorial

Ein **Request**body sind Daten, die vom Client zu Ihrer API gesendet werden. Ein **Response**body (Deutsch: Antwortkörper) sind Daten, die Ihre API zum Client sendet.

Ihre API sendet fast immer einen **Response**body. Aber Clients senden nicht unbedingt immer **Request**bodys (sondern nur Metadaten).