19 changed files with 829 additions and 905 deletions
@ -1,17 +1,18 @@ |
|||
# FastAPI-Deployment bei Cloud-Anbietern |
|||
# FastAPI bei Cloudanbietern bereitstellen |
|||
|
|||
Sie können praktisch **jeden Cloud-Anbieter** für das <abbr title="Bereitstellen der fertigen Anwendung für die Endbenutzer">Deployment</abbr> Ihrer FastAPI-Anwendung verwenden. |
|||
Sie können praktisch **jeden Cloudanbieter** verwenden, um Ihre FastAPI-Anwendung bereitzustellen. |
|||
|
|||
In den meisten Fällen verfügen die Haupt-Cloud-Anbieter über Anleitungen zum Deployment von FastAPI. |
|||
In den meisten Fällen bieten die großen Cloudanbieter Anleitungen zum Bereitstellen von FastAPI an. |
|||
|
|||
## Cloud-Anbieter – Sponsoren |
|||
## Cloudanbieter - Sponsoren |
|||
|
|||
Einige Cloud-Anbieter ✨ [**sponsern FastAPI**](../help-fastapi.md#den-autor-sponsern){.internal-link target=_blank} ✨, dies gewährleistet die kontinuierliche und gesunde **Entwicklung** von FastAPI und seinem **Ökosystem**. |
|||
Einige Cloudanbieter ✨ [**sponsern FastAPI**](../help-fastapi.md#den-autor-sponsern){.internal-link target=_blank} ✨, dies stellt die kontinuierliche und gesunde **Entwicklung** von FastAPI und seinem **Ökosystem** sicher. |
|||
|
|||
Und es zeigt deren wahres Engagement für FastAPI und seine **Community** (Sie), da diese Ihnen nicht nur einen **guten Service** bieten möchten, sondern auch sicherstellen möchten, dass Sie über ein **gutes und gesundes Framework** verfügen, FastAPI. 🙇 |
|||
Und es zeigt ihr wahres Engagement für FastAPI und seine **Community** (Sie), da sie Ihnen nicht nur einen **guten Service** bieten möchten, sondern auch sicherstellen möchten, dass Sie ein **gutes und gesundes Framework**, FastAPI, haben. 🙇 |
|||
|
|||
Vielleicht möchten Sie deren Dienste ausprobieren und deren Anleitungen folgen: |
|||
|
|||
* <a href="https://docs.platform.sh/languages/python.html?utm_source=fastapi-signup&utm_medium=banner&utm_campaign=FastAPI-signup-June-2023" class="external-link" target="_blank">Platform.sh</a> |
|||
* <a href="https://docs.porter.run/language-specific-guides/fastapi" class="external-link" target="_blank">Porter</a> |
|||
* <a href="https://docs.withcoherence.com/docs/configuration/frameworks?utm_medium=advertising&utm_source=fastapi&utm_campaign=banner%20january%2024#fast-api-example" class="external-link" target="_blank">Coherence</a> |
|||
* <a href="https://docs.render.com/deploy-fastapi?utm_source=deploydoc&utm_medium=referral&utm_campaign=fastapi" class="external-link" target="_blank">Render</a> |
|||
* <a href="https://docs.railway.com/guides/fastapi?utm_medium=integration&utm_source=docs&utm_campaign=fastapi" class="external-link" target="_blank">Railway</a> |
|||
|
|||
@ -1,84 +1,28 @@ |
|||
# Projektgenerierung – Vorlage |
|||
|
|||
Sie können einen Projektgenerator für den Einstieg verwenden, welcher einen Großteil der Ersteinrichtung, Sicherheit, Datenbank und einige API-Endpunkte bereits für Sie erstellt. |
|||
|
|||
Ein Projektgenerator verfügt immer über ein sehr spezifisches Setup, das Sie aktualisieren und an Ihre eigenen Bedürfnisse anpassen sollten, aber es könnte ein guter Ausgangspunkt für Ihr Projekt sein. |
|||
|
|||
## Full Stack FastAPI PostgreSQL |
|||
|
|||
GitHub: <a href="https://github.com/tiangolo/full-stack-fastapi-postgresql" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-fastapi-postgresql</a> |
|||
|
|||
### Full Stack FastAPI PostgreSQL – Funktionen |
|||
|
|||
* Vollständige **Docker**-Integration (Docker-basiert). |
|||
* Docker-Schwarmmodus-Deployment. |
|||
* **Docker Compose**-Integration und Optimierung für die lokale Entwicklung. |
|||
* **Produktionsbereit** Python-Webserver, verwendet Uvicorn und Gunicorn. |
|||
* Python <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">**FastAPI**</a>-Backend: |
|||
* **Schnell**: Sehr hohe Leistung, auf Augenhöhe mit **NodeJS** und **Go** (dank Starlette und Pydantic). |
|||
* **Intuitiv**: Hervorragende Editor-Unterstützung. <abbr title="Auch bekannt als automatische Vervollständigung, IntelliSense">Codevervollständigung</abbr> überall. Weniger Zeitaufwand für das Debuggen. |
|||
* **Einfach**: Einfach zu bedienen und zu erlernen. Weniger Zeit für das Lesen von Dokumentationen. |
|||
* **Kurz**: Codeverdoppelung minimieren. Mehrere Funktionalitäten aus jeder Parameterdeklaration. |
|||
* **Robust**: Erhalten Sie produktionsbereiten Code. Mit automatischer, interaktiver Dokumentation. |
|||
* **Standards-basiert**: Basierend auf (und vollständig kompatibel mit) den offenen Standards für APIs: <a href="https://github.com/OAI/OpenAPI-Specification" class="external-link" target="_blank">OpenAPI</a> und <a href="https://json-schema.org/" class="external-link" target="_blank">JSON Schema</a>. |
|||
* <a href="https://fastapi.tiangolo.com/features/" class="external-link" target="_blank">**Viele weitere Funktionen**</a>, einschließlich automatischer Validierung, Serialisierung, interaktiver Dokumentation, Authentifizierung mit OAuth2-JWT-Tokens, usw. |
|||
* **Sicheres Passwort**-Hashing standardmäßig. |
|||
* **JWT-Token**-Authentifizierung. |
|||
* **SQLAlchemy**-Modelle (unabhängig von Flask-Erweiterungen, sodass sie direkt mit Celery-Workern verwendet werden können). |
|||
* Grundlegende Startmodelle für Benutzer (ändern und entfernen Sie nach Bedarf). |
|||
* **Alembic**-Migrationen. |
|||
* **CORS** (Cross Origin Resource Sharing). |
|||
* **Celery**-Worker, welche Modelle und Code aus dem Rest des Backends selektiv importieren und verwenden können. |
|||
* REST-Backend-Tests basierend auf **Pytest**, integriert in Docker, sodass Sie die vollständige API-Interaktion unabhängig von der Datenbank testen können. Da es in Docker ausgeführt wird, kann jedes Mal ein neuer Datenspeicher von Grund auf erstellt werden (Sie können also ElasticSearch, MongoDB, CouchDB oder was auch immer Sie möchten verwenden und einfach testen, ob die API funktioniert). |
|||
* Einfache Python-Integration mit **Jupyter-Kerneln** für Remote- oder In-Docker-Entwicklung mit Erweiterungen wie Atom Hydrogen oder Visual Studio Code Jupyter. |
|||
* **Vue**-Frontend: |
|||
* Mit Vue CLI generiert. |
|||
* Handhabung der **JWT-Authentifizierung**. |
|||
* Login-View. |
|||
* Nach der Anmeldung Hauptansicht des Dashboards. |
|||
* Haupt-Dashboard mit Benutzererstellung und -bearbeitung. |
|||
* Bearbeitung des eigenen Benutzers. |
|||
* **Vuex**. |
|||
* **Vue-Router**. |
|||
* **Vuetify** für schöne Material-Designkomponenten. |
|||
* **TypeScript**. |
|||
* Docker-Server basierend auf **Nginx** (konfiguriert, um gut mit Vue-Router zu funktionieren). |
|||
* Mehrstufigen Docker-Erstellung, sodass Sie kompilierten Code nicht speichern oder committen müssen. |
|||
* Frontend-Tests, welche zur Erstellungszeit ausgeführt werden (können auch deaktiviert werden). |
|||
* So modular wie möglich gestaltet, sodass es sofort einsatzbereit ist. Sie können es aber mit Vue CLI neu generieren oder es so wie Sie möchten erstellen und wiederverwenden, was Sie möchten. |
|||
* **PGAdmin** für die PostgreSQL-Datenbank, können Sie problemlos ändern, sodass PHPMyAdmin und MySQL verwendet wird. |
|||
* **Flower** für die Überwachung von Celery-Jobs. |
|||
* Load Balancing zwischen Frontend und Backend mit **Traefik**, sodass Sie beide unter derselben Domain haben können, getrennt durch den Pfad, aber von unterschiedlichen Containern ausgeliefert. |
|||
* Traefik-Integration, einschließlich automatischer Generierung von Let's Encrypt-**HTTPS**-Zertifikaten. |
|||
* GitLab **CI** (kontinuierliche Integration), einschließlich Frontend- und Backend-Testen. |
|||
|
|||
## Full Stack FastAPI Couchbase |
|||
|
|||
GitHub: <a href="https://github.com/tiangolo/full-stack-fastapi-couchbase" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-fastapi-couchbase</a> |
|||
|
|||
⚠️ **WARNUNG** ⚠️ |
|||
|
|||
Wenn Sie ein neues Projekt von Grund auf starten, prüfen Sie die Alternativen hier. |
|||
|
|||
Zum Beispiel könnte der Projektgenerator <a href="https://github.com/tiangolo/full-stack-fastapi-postgresql" class="external-link" target="_blank">Full Stack FastAPI PostgreSQL</a> eine bessere Alternative sein, da er aktiv gepflegt und genutzt wird. Und er enthält alle neuen Funktionen und Verbesserungen. |
|||
|
|||
Es steht Ihnen weiterhin frei, den Couchbase-basierten Generator zu verwenden, wenn Sie möchten. Er sollte wahrscheinlich immer noch gut funktionieren, und wenn Sie bereits ein Projekt damit erstellt haben, ist das auch in Ordnung (und Sie haben es wahrscheinlich bereits an Ihre Bedürfnisse angepasst). |
|||
|
|||
Weitere Informationen hierzu finden Sie in der Dokumentation des Repos. |
|||
|
|||
## Full Stack FastAPI MongoDB |
|||
|
|||
... könnte später kommen, abhängig von meiner verfügbaren Zeit und anderen Faktoren. 😅 🎉 |
|||
|
|||
## Modelle für maschinelles Lernen mit spaCy und FastAPI |
|||
|
|||
GitHub: <a href="https://github.com/microsoft/cookiecutter-spacy-fastapi" class="external-link" target="_blank">https://github.com/microsoft/cookiecutter-spacy-fastapi</a> |
|||
|
|||
### Modelle für maschinelles Lernen mit spaCy und FastAPI – Funktionen |
|||
|
|||
* **spaCy** NER-Modellintegration. |
|||
* **Azure Cognitive Search**-Anforderungsformat integriert. |
|||
* **Produktionsbereit** Python-Webserver, verwendet Uvicorn und Gunicorn. |
|||
* **Azure DevOps** Kubernetes (AKS) CI/CD-Deployment integriert. |
|||
* **Mehrsprachig** Wählen Sie bei der Projekteinrichtung ganz einfach eine der integrierten Sprachen von spaCy aus. |
|||
* **Einfach erweiterbar** auf andere Modellframeworks (Pytorch, Tensorflow), nicht nur auf SpaCy. |
|||
# Full Stack FastAPI Template |
|||
|
|||
Vorlagen, die normalerweise mit einem bestimmten Setup geliefert werden, sind so konzipiert, dass sie flexibel und anpassbar sind. Dies ermöglicht es Ihnen, sie zu modifizieren und an die Anforderungen Ihres Projekts anzupassen und sie somit zu einem hervorragenden Ausgangspunkt zu machen. 🏁 |
|||
|
|||
Sie können folgende Vorlage verwenden, um loszulegen, da sie bereits vieles der anfänglichen Einrichtung, Sicherheit, Datenbank und einige API-Endpunkte für Sie eingerichtet hat. |
|||
|
|||
GitHub-Repository: <a href="https://github.com/tiangolo/full-stack-fastapi-template" class="external-link" target="_blank">Full Stack FastAPI Template</a> |
|||
|
|||
## Full Stack FastAPI Template - Technologiestack und Funktionen |
|||
|
|||
- ⚡ [**FastAPI**](https://fastapi.tiangolo.com) für die Python-Backend-API. |
|||
- 🧰 [SQLModel](https://sqlmodel.tiangolo.com) für die Interaktion mit der Python-SQL-Datenbank (ORM). |
|||
- 🔍 [Pydantic](https://docs.pydantic.dev), verwendet von FastAPI, für die Datenvalidierung und das Einstellungsmanagement. |
|||
- 💾 [PostgreSQL](https://www.postgresql.org) als SQL-Datenbank. |
|||
- 🚀 [React](https://react.dev) für das Frontend. |
|||
- 💃 Verwendung von TypeScript, Hooks, [Vite](https://vitejs.dev) und anderen Teilen eines modernen Frontend-Stacks. |
|||
- 🎨 [Chakra UI](https://chakra-ui.com) für die Frontend-Komponenten. |
|||
- 🤖 Ein automatisch generierter Frontend-Client. |
|||
- 🧪 [Playwright](https://playwright.dev) für End-to-End-Tests. |
|||
- 🦇 Unterstützung des Dunkelmodus. |
|||
- 🐋 [Docker Compose](https://www.docker.com) für Entwicklung und Produktion. |
|||
- 🔒 Sicheres Passwort-Hashing standardmäßig. |
|||
- 🔑 JWT-Token-Authentifizierung. |
|||
- 📫 E-Mail-basierte Passwortwiederherstellung. |
|||
- ✅ Tests mit [Pytest](https://pytest.org). |
|||
- 📞 [Traefik](https://traefik.io) als Reverse-Proxy / Load Balancer. |
|||
- 🚢 Deployment-Anleitungen unter Verwendung von Docker Compose, einschließlich der Einrichtung eines Frontend-Traefik-Proxys zur Handhabung automatischer HTTPS-Zertifikate. |
|||
- 🏭 CI (kontinuierliche Integration) und CD (kontinuierliche Bereitstellung) basierend auf GitHub Actions. |
|||
|
|||
@ -1,38 +1,38 @@ |
|||
# Extramodelle |
|||
|
|||
Fahren wir beim letzten Beispiel fort. Es gibt normalerweise mehrere zusammengehörende Modelle. |
|||
Im Anschluss an das vorherige Beispiel ist es üblich, mehr als ein zusammenhängendes Modell zu haben. |
|||
|
|||
Insbesondere Benutzermodelle, denn: |
|||
Dies gilt insbesondere für Benutzermodelle, denn: |
|||
|
|||
* Das **hereinkommende Modell** sollte ein Passwort haben können. |
|||
* Das **herausgehende Modell** sollte kein Passwort haben. |
|||
* Das **Datenbankmodell** sollte wahrscheinlich ein <abbr title='Ein aus scheinbar zufälligen Zeichen bestehender „Fingerabdruck“ eines Textes. Der Inhalt des Textes kann nicht eingesehen werden.'>gehashtes</abbr> Passwort haben. |
|||
* Das **Eingabemodell** muss ein Passwort enthalten können. |
|||
* Das **Ausgabemodell** sollte kein Passwort haben. |
|||
* Das **Datenbankmodell** müsste wahrscheinlich ein gehashtes Passwort haben. |
|||
|
|||
/// danger | Gefahr |
|||
|
|||
Speichern Sie niemals das Klartext-Passwort eines Benutzers. Speichern Sie immer den „sicheren Hash“, den Sie verifizieren können. |
|||
Speichern Sie niemals das Klartextpasswort eines Benutzers. Speichern Sie immer einen „sicheren Hash“, den Sie dann verifizieren können. |
|||
|
|||
Falls Ihnen das nichts sagt, in den [Sicherheits-Kapiteln](security/simple-oauth2.md#passwort-hashing){.internal-link target=_blank} werden Sie lernen, was ein „Passwort-Hash“ ist. |
|||
Wenn Sie nicht wissen, was das ist, werden Sie in den [Sicherheitskapiteln](security/simple-oauth2.md#password-hashing){.internal-link target=_blank} lernen, was ein „Passworthash“ ist. |
|||
|
|||
/// |
|||
|
|||
## Mehrere Modelle |
|||
|
|||
Hier der generelle Weg, wie die Modelle mit ihren Passwort-Feldern aussehen könnten, und an welchen Orten sie verwendet werden würden. |
|||
Hier ist eine allgemeine Idee, wie die Modelle mit ihren Passwortfeldern aussehen könnten und an welchen Stellen sie verwendet werden: |
|||
|
|||
{* ../../docs_src/extra_models/tutorial001_py310.py hl[7,9,14,20,22,27:28,31:33,38:39] *} |
|||
|
|||
/// info |
|||
/// info | Info |
|||
|
|||
In Pydantic v1 hieß diese Methode `.dict()`, in Pydantic v2 wurde sie deprecated (aber immer noch unterstützt) und in `.model_dump()` umbenannt. |
|||
In Pydantic v1 hieß die Methode `.dict()`, in Pydantic v2 wurde sie als veraltet markiert (aber weiterhin unterstützt) und in `.model_dump()` umbenannt. |
|||
|
|||
Die Beispiele hier verwenden `.dict()` für die Kompatibilität mit Pydantic v1, Sie sollten jedoch stattdessen `.model_dump()` verwenden, wenn Sie Pydantic v2 verwenden können. |
|||
Die Beispiele hier verwenden `.dict()` für die Kompatibilität mit Pydantic v1, aber Sie sollten `.model_dump()` verwenden, wenn Sie Pydantic v2 verwenden können. |
|||
|
|||
/// |
|||
|
|||
### Über `**user_in.dict()` |
|||
|
|||
#### Pydantic's `.dict()` |
|||
#### Die `.dict()` Methode von Pydantic |
|||
|
|||
`user_in` ist ein Pydantic-Modell der Klasse `UserIn`. |
|||
|
|||
@ -44,21 +44,21 @@ Wenn wir also ein Pydantic-Objekt `user_in` erstellen, etwa so: |
|||
user_in = UserIn(username="john", password="secret", email="[email protected]") |
|||
``` |
|||
|
|||
und wir rufen seine `.dict()`-Methode auf: |
|||
und dann aufrufen: |
|||
|
|||
```Python |
|||
user_dict = user_in.dict() |
|||
``` |
|||
|
|||
dann haben wir jetzt in der Variable `user_dict` ein `dict` mit den gleichen Daten (es ist ein `dict` statt eines Pydantic-Modellobjekts). |
|||
haben wir jetzt ein `dict` mit den Daten in der Variablen `user_dict` (es ist ein `dict` statt eines Pydantic-Modellobjekts). |
|||
|
|||
Wenn wir es ausgeben: |
|||
Und wenn wir aufrufen: |
|||
|
|||
```Python |
|||
print(user_dict) |
|||
``` |
|||
|
|||
bekommen wir ein Python-`dict`: |
|||
würden wir ein Python-`dict` erhalten mit: |
|||
|
|||
```Python |
|||
{ |
|||
@ -71,15 +71,15 @@ bekommen wir ein Python-`dict`: |
|||
|
|||
#### Ein `dict` entpacken |
|||
|
|||
Wenn wir ein `dict` wie `user_dict` nehmen, und es einer Funktion (oder Klassenmethode) mittels `**user_dict` übergeben, wird Python es „entpacken“. Es wird die Schlüssel und Werte von `user_dict` direkt als Schlüsselwort-Argumente übergeben. |
|||
Wenn wir ein `dict` wie `user_dict` nehmen und es einer Funktion (oder Klasse) mit `**user_dict` übergeben, wird Python es „entpacken“. Es wird die Schlüssel und Werte von `user_dict` direkt als Schlüsselwort-Argumente übergeben. |
|||
|
|||
Wenn wir also das `user_dict` von oben nehmen und schreiben: |
|||
Setzen wir also das `user_dict` von oben ein: |
|||
|
|||
```Python |
|||
UserInDB(**user_dict) |
|||
``` |
|||
|
|||
dann ist das ungefähr äquivalent zu: |
|||
so ist das äquivalent zu: |
|||
|
|||
```Python |
|||
UserInDB( |
|||
@ -90,7 +90,7 @@ UserInDB( |
|||
) |
|||
``` |
|||
|
|||
Oder, präziser, `user_dict` wird direkt verwendet, welche Werte es auch immer haben mag: |
|||
Oder genauer gesagt, dazu, `user_dict` direkt zu verwenden, mit welchen Inhalten es auch immer in der Zukunft haben mag: |
|||
|
|||
```Python |
|||
UserInDB( |
|||
@ -101,34 +101,34 @@ UserInDB( |
|||
) |
|||
``` |
|||
|
|||
#### Ein Pydantic-Modell aus den Inhalten eines anderen erstellen. |
|||
#### Ein Pydantic-Modell aus dem Inhalt eines anderen |
|||
|
|||
Da wir in obigem Beispiel `user_dict` mittels `user_in.dict()` erzeugt haben, ist dieser Code: |
|||
Da wir im obigen Beispiel `user_dict` von `user_in.dict()` bekommen haben, wäre dieser Code: |
|||
|
|||
```Python |
|||
user_dict = user_in.dict() |
|||
UserInDB(**user_dict) |
|||
``` |
|||
|
|||
äquivalent zu: |
|||
gleichwertig zu: |
|||
|
|||
```Python |
|||
UserInDB(**user_in.dict()) |
|||
``` |
|||
|
|||
... weil `user_in.dict()` ein `dict` ist, und dann lassen wir Python es „entpacken“, indem wir es `UserInDB` übergeben, mit vorangestelltem `**`. |
|||
...weil `user_in.dict()` ein `dict` ist, und dann lassen wir Python es „entpacken“, indem wir es an `UserInDB` mit vorangestelltem `**` übergeben. |
|||
|
|||
Wir erhalten also ein Pydantic-Modell aus den Daten eines anderen Pydantic-Modells. |
|||
Auf diese Weise erhalten wir ein Pydantic-Modell aus den Daten eines anderen Pydantic-Modells. |
|||
|
|||
#### Ein `dict` entpacken und zusätzliche Schlüsselwort-Argumente |
|||
|
|||
Und dann fügen wir ein noch weiteres Schlüsselwort-Argument hinzu, `hashed_password=hashed_password`: |
|||
Und dann fügen wir das zusätzliche Schlüsselwort-Argument `hashed_password=hashed_password` hinzu, wie in: |
|||
|
|||
```Python |
|||
UserInDB(**user_in.dict(), hashed_password=hashed_password) |
|||
``` |
|||
|
|||
... was am Ende ergibt: |
|||
...was so ist wie: |
|||
|
|||
```Python |
|||
UserInDB( |
|||
@ -142,39 +142,39 @@ UserInDB( |
|||
|
|||
/// warning | Achtung |
|||
|
|||
Die Hilfsfunktionen `fake_password_hasher` und `fake_save_user` demonstrieren nur den möglichen Fluss der Daten und bieten natürlich keine echte Sicherheit. |
|||
Die unterstützenden zusätzlichen Funktionen `fake_password_hasher` und `fake_save_user` dienen nur zur Demo eines möglichen Datenflussses, bieten jedoch natürlich keine echte Sicherheit. |
|||
|
|||
/// |
|||
|
|||
## Verdopplung vermeiden |
|||
|
|||
Reduzierung von Code-Verdoppelung ist eine der Kern-Ideen von **FastAPI**. |
|||
Die Reduzierung von Code-Verdoppelung ist eine der Kernideen von **FastAPI**. |
|||
|
|||
Weil Verdoppelung von Code die Wahrscheinlichkeit von Fehlern, Sicherheitsproblemen, Desynchronisation (Code wird nur an einer Stelle verändert, aber nicht an einer anderen), usw. erhöht. |
|||
Da die Verdopplung von Code die Wahrscheinlichkeit von Fehlern, Sicherheitsproblemen, Problemen mit der Desynchronisation des Codes (wenn Sie an einer Stelle, aber nicht an der anderen aktualisieren) usw. erhöht. |
|||
|
|||
Unsere Modelle teilen alle eine Menge der Daten und verdoppeln Attribut-Namen und -Typen. |
|||
Und diese Modelle teilen alle eine Menge der Daten und verdoppeln Attributnamen und -typen. |
|||
|
|||
Das können wir besser machen. |
|||
Wir könnten es besser machen. |
|||
|
|||
Wir deklarieren ein `UserBase`-Modell, das als Basis für unsere anderen Modelle dient. Dann können wir Unterklassen erstellen, die seine Attribute (Typdeklarationen, Validierungen, usw.) erben. |
|||
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 gehabt funktionieren. |
|||
Die ganze Datenkonvertierung, Validierung, Dokumentation usw. wird immer noch wie gewohnt funktionieren. |
|||
|
|||
Auf diese Weise beschreiben wir nur noch die Unterschiede zwischen den Modellen (mit Klartext-`password`, mit `hashed_password`, und ohne Passwort): |
|||
Auf diese Weise können wir nur die Unterschiede zwischen den Modellen (mit Klartext-`password`, mit `hashed_password` und ohne Passwort) deklarieren: |
|||
|
|||
{* ../../docs_src/extra_models/tutorial002_py310.py hl[7,13:14,17:18,21:22] *} |
|||
|
|||
## `Union`, oder `anyOf` |
|||
## `Union` oder `anyOf` |
|||
|
|||
Sie können deklarieren, dass eine Response eine <abbr title="Union – Verbund, Einheit‚ Vereinigung: Eines von Mehreren">`Union`</abbr> mehrerer Typen ist, sprich, einer dieser Typen. |
|||
Sie können deklarieren, dass eine Response eine <abbr title="Union – Verbund, Einheit, Vereinigung: Eines von Mehreren">`Union`</abbr> mehrerer Typen ist, das bedeutet, dass die Response einer von ihnen ist. |
|||
|
|||
Das wird in OpenAPI mit `anyOf` angezeigt. |
|||
Dies wird in OpenAPI mit `anyOf` definiert. |
|||
|
|||
Um das zu tun, verwenden Sie Pythons Standard-Typhinweis <a href="https://docs.python.org/3/library/typing.html#typing.Union" class="external-link" target="_blank">`typing.Union`</a>: |
|||
Um das zu tun, verwenden Sie den Standard-Python-Typhinweis <a href="https://docs.python.org/3/library/typing.html#typing.Union" class="external-link" target="_blank">`typing.Union`</a>: |
|||
|
|||
/// note | Hinweis |
|||
|
|||
Listen Sie, wenn Sie eine <a href="https://pydantic-docs.helpmanual.io/usage/types/#unions" class="external-link" target="_blank">`Union`</a> definieren, denjenigen Typ zuerst, der am spezifischsten ist, gefolgt von den weniger spezifischen Typen. Im Beispiel oben, in `Union[PlaneItem, CarItem]` also den spezifischeren `PlaneItem` vor dem weniger spezifischen `CarItem`. |
|||
Wenn Sie eine <a href="https://docs.pydantic.dev/latest/concepts/types/#unions" class="external-link" target="_blank">`Union`</a> definieren, listen Sie den spezifischeren Typ zuerst auf, gefolgt vom weniger spezifischen Typ. Im Beispiel unten steht `PlaneItem` vor `CarItem` in `Union[PlaneItem, CarItem]`. |
|||
|
|||
/// |
|||
|
|||
@ -182,33 +182,33 @@ Listen Sie, wenn Sie eine <a href="https://pydantic-docs.helpmanual.io/usage/typ |
|||
|
|||
### `Union` in Python 3.10 |
|||
|
|||
In diesem Beispiel übergeben wir dem Argument `response_model` den Wert `Union[PlaneItem, CarItem]`. |
|||
In diesem Beispiel übergeben wir `Union[PlaneItem, CarItem]` als Wert des Arguments `response_model`. |
|||
|
|||
Da wir es als **Wert einem Argument überreichen**, statt es als **Typannotation** zu verwenden, müssen wir `Union` verwenden, selbst in Python 3.10. |
|||
Da wir es als **Wert an ein Argument übergeben**, anstatt es in einer **Typannotation** zu verwenden, müssen wir `Union` verwenden, sogar in Python 3.10. |
|||
|
|||
Wenn es eine Typannotation gewesen wäre, hätten wir auch den vertikalen Trennstrich verwenden können, wie in: |
|||
Wäre es eine Typannotation gewesen, hätten wir den vertikalen Strich verwenden können, wie in: |
|||
|
|||
```Python |
|||
some_variable: PlaneItem | CarItem |
|||
``` |
|||
|
|||
Aber wenn wir das in der Zuweisung `response_model=PlaneItem | CarItem` machen, erhalten wir eine Fehlermeldung, da Python versucht, eine **ungültige Operation** zwischen `PlaneItem` und `CarItem` durchzuführen, statt es als Typannotation zu interpretieren. |
|||
Aber wenn wir das in der Zuweisung `response_model=PlaneItem | CarItem` machen, würden wir einen Fehler erhalten, weil Python versuchen würde, eine **ungültige Operation** zwischen `PlaneItem` und `CarItem` auszuführen, anstatt es als Typannotation zu interpretieren. |
|||
|
|||
## Listen von Modellen |
|||
## Liste von Modellen |
|||
|
|||
Genauso können Sie eine Response deklarieren, die eine Liste von Objekten ist. |
|||
Auf die gleiche Weise können Sie Responses von Listen von Objekten deklarieren. |
|||
|
|||
Verwenden Sie dafür Pythons Standard `typing.List` (oder nur `list` in Python 3.9 und darüber): |
|||
Dafür verwenden Sie das Standard-Python `typing.List` (oder nur `list` in Python 3.9 und höher): |
|||
|
|||
{* ../../docs_src/extra_models/tutorial004_py39.py hl[18] *} |
|||
|
|||
## Response mit beliebigem `dict` |
|||
|
|||
Sie könne auch eine Response deklarieren, die ein beliebiges `dict` zurückgibt, bei dem nur die Typen der Schlüssel und der Werte bekannt sind, ohne ein Pydantic-Modell zu verwenden. |
|||
Sie können auch eine Response deklarieren, die ein beliebiges `dict` zurückgibt, indem Sie nur die Typen der Schlüssel und Werte ohne ein Pydantic-Modell deklarieren. |
|||
|
|||
Das ist nützlich, wenn Sie die gültigen Feld-/Attribut-Namen von vorneherein nicht wissen (was für ein Pydantic-Modell notwendig ist). |
|||
Dies ist nützlich, wenn Sie die gültigen Feld-/Attributnamen nicht im Voraus kennen (die für ein Pydantic-Modell benötigt werden würden). |
|||
|
|||
In diesem Fall können Sie `typing.Dict` verwenden (oder nur `dict` in Python 3.9 und darüber): |
|||
In diesem Fall können Sie `typing.Dict` verwenden (oder nur `dict` in Python 3.9 und höher): |
|||
|
|||
{* ../../docs_src/extra_models/tutorial005_py39.py hl[6] *} |
|||
|
|||
@ -216,4 +216,4 @@ In diesem Fall können Sie `typing.Dict` verwenden (oder nur `dict` in Python 3. |
|||
|
|||
Verwenden Sie gerne mehrere Pydantic-Modelle und vererben Sie je nach Bedarf. |
|||
|
|||
Sie brauchen kein einzelnes Datenmodell pro Einheit, wenn diese Einheit verschiedene Zustände annehmen kann. So wie unsere Benutzer-„Einheit“, welche einen Zustand mit `password`, einen mit `password_hash` und einen ohne Passwort hatte. |
|||
Sie brauchen kein einzelnes Datenmodell pro Einheit, wenn diese Einheit in der Lage sein muss, verschiedene „Zustände“ zu haben. Wie im Fall der Benutzer-„Einheit“ mit einem Zustand einschließlich `password`, `password_hash` und ohne Passwort. |
|||
|
|||
Loading…
Reference in new issue