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.
- Das Datenbankmodell sollte wahrscheinlich ein gehashtes Passwort haben.
Gefahr
Speichern Sie niemals das Klartext-Passwort eines Benutzers. Speichern Sie immer den „sicheren Hash“, den Sie verifizieren können.
Falls Ihnen das nichts sagt, in den Sicherheits-Kapiteln werden Sie lernen, was ein „Passwort-Hash“ 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.
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr
app = FastAPI()
class UserIn(BaseModel):
username: str
password: str
email: EmailStr
full_name: str | None = None
class UserOut(BaseModel):
username: str
email: EmailStr
full_name: str | None = None
class UserInDB(BaseModel):
username: str
hashed_password: str
email: EmailStr
full_name: str | None = None
def fake_password_hasher(raw_password: str):
return "supersecret" + raw_password
def fake_save_user(user_in: UserIn):
hashed_password = fake_password_hasher(user_in.password)
user_in_db = UserInDB(**user_in.dict(), hashed_password=hashed_password)
print("User saved! ..not really")
return user_in_db
@app.post("/user/", response_model=UserOut)
async def create_user(user_in: UserIn):
user_saved = fake_save_user(user_in)
return user_saved
from typing import Union
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr
app = FastAPI()
class UserIn(BaseModel):
username: str
password: str
email: EmailStr
full_name: Union[str, None] = None
class UserOut(BaseModel):
username: str
email: EmailStr
full_name: Union[str, None] = None
class UserInDB(BaseModel):
username: str
hashed_password: str
email: EmailStr
full_name: Union[str, None] = None
def fake_password_hasher(raw_password: str):
return "supersecret" + raw_password
def fake_save_user(user_in: UserIn):
hashed_password = fake_password_hasher(user_in.password)
user_in_db = UserInDB(**user_in.dict(), hashed_password=hashed_password)
print("User saved! ..not really")
return user_in_db
@app.post("/user/", response_model=UserOut)
async def create_user(user_in: UserIn):
user_saved = fake_save_user(user_in)
return user_saved
Info
In Pydantic v1 hieß diese Methode .dict(), in Pydantic v2 wurde sie deprecated (aber immer noch 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.
Über **user_in.dict()¶
Pydantic's .dict()¶
user_in ist ein Pydantic-Modell der Klasse UserIn.
Pydantic-Modelle haben eine .dict()-Methode, die ein dict mit den Daten des Modells zurückgibt.
Wenn wir also ein Pydantic-Objekt user_in erstellen, etwa so:
user_in = UserIn(username="john", password="secret", email="john.doe@example.com")
und wir rufen seine .dict()-Methode auf:
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).
Wenn wir es ausgeben:
print(user_dict)
bekommen wir ein Python-dict:
{
'username': 'john',
'password': 'secret',
'email': 'john.doe@example.com',
'full_name': None,
}
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 also das user_dict von oben nehmen und schreiben:
UserInDB(**user_dict)
dann ist das ungefähr äquivalent zu:
UserInDB(
username="john",
password="secret",
email="john.doe@example.com",
full_name=None,
)
Oder, präziser, user_dict wird direkt verwendet, welche Werte es auch immer haben mag:
UserInDB(
username = user_dict["username"],
password = user_dict["password"],
email = user_dict["email"],
full_name = user_dict["full_name"],
)
Ein Pydantic-Modell aus den Inhalten eines anderen erstellen.¶
Da wir in obigem Beispiel user_dict mittels user_in.dict() erzeugt haben, ist dieser Code:
user_dict = user_in.dict()
UserInDB(**user_dict)
äquivalent zu:
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 **.
Wir erhalten also 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:
UserInDB(**user_in.dict(), hashed_password=hashed_password)
... was am Ende ergibt:
UserInDB(
username = user_dict["username"],
password = user_dict["password"],
email = user_dict["email"],
full_name = user_dict["full_name"],
hashed_password = hashed_password,
)
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.
Verdopplung vermeiden¶
Reduzierung von Code-Verdoppelung ist eine der Kern-Ideen 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.
Unsere Modelle teilen alle eine Menge der Daten und verdoppeln Attribut-Namen und -Typen.
Das können wir 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.
Die ganze Datenkonvertierung, -validierung, -dokumentation, usw. wird immer noch wie gehabt funktionieren.
Auf diese Weise beschreiben wir nur noch die Unterschiede zwischen den Modellen (mit Klartext-password, mit hashed_password, und ohne Passwort):
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr
app = FastAPI()
class UserBase(BaseModel):
username: str
email: EmailStr
full_name: str | None = None
class UserIn(UserBase):
password: str
class UserOut(UserBase):
pass
class UserInDB(UserBase):
hashed_password: str
def fake_password_hasher(raw_password: str):
return "supersecret" + raw_password
def fake_save_user(user_in: UserIn):
hashed_password = fake_password_hasher(user_in.password)
user_in_db = UserInDB(**user_in.dict(), hashed_password=hashed_password)
print("User saved! ..not really")
return user_in_db
@app.post("/user/", response_model=UserOut)
async def create_user(user_in: UserIn):
user_saved = fake_save_user(user_in)
return user_saved
from typing import Union
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr
app = FastAPI()
class UserBase(BaseModel):
username: str
email: EmailStr
full_name: Union[str, None] = None
class UserIn(UserBase):
password: str
class UserOut(UserBase):
pass
class UserInDB(UserBase):
hashed_password: str
def fake_password_hasher(raw_password: str):
return "supersecret" + raw_password
def fake_save_user(user_in: UserIn):
hashed_password = fake_password_hasher(user_in.password)
user_in_db = UserInDB(**user_in.dict(), hashed_password=hashed_password)
print("User saved! ..not really")
return user_in_db
@app.post("/user/", response_model=UserOut)
async def create_user(user_in: UserIn):
user_saved = fake_save_user(user_in)
return user_saved
Union, oder anyOf¶
Sie können deklarieren, dass eine Response eine Union mehrerer Typen ist, sprich, einer dieser Typen.
Das wird in OpenAPI mit anyOf angezeigt.
Um das zu tun, verwenden Sie Pythons Standard-Typhinweis typing.Union:
Hinweis
Listen Sie, wenn Sie eine Union 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.
from typing import Union
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class BaseItem(BaseModel):
description: str
type: str
class CarItem(BaseItem):
type: str = "car"
class PlaneItem(BaseItem):
type: str = "plane"
size: int
items = {
"item1": {"description": "All my friends drive a low rider", "type": "car"},
"item2": {
"description": "Music is my aeroplane, it's my aeroplane",
"type": "plane",
"size": 5,
},
}
@app.get("/items/{item_id}", response_model=Union[PlaneItem, CarItem])
async def read_item(item_id: str):
return items[item_id]
from typing import Union
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class BaseItem(BaseModel):
description: str
type: str
class CarItem(BaseItem):
type: str = "car"
class PlaneItem(BaseItem):
type: str = "plane"
size: int
items = {
"item1": {"description": "All my friends drive a low rider", "type": "car"},
"item2": {
"description": "Music is my aeroplane, it's my aeroplane",
"type": "plane",
"size": 5,
},
}
@app.get("/items/{item_id}", response_model=Union[PlaneItem, CarItem])
async def read_item(item_id: str):
return items[item_id]
Union in Python 3.10¶
In diesem Beispiel übergeben wir dem Argument response_model den Wert Union[PlaneItem, CarItem].
Da wir es als Wert einem Argument überreichen, statt es als Typannotation zu verwenden, müssen wir Union verwenden, selbst in Python 3.10.
Wenn es eine Typannotation gewesen wäre, hätten wir auch den vertikalen Trennstrich verwenden können, wie in:
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.
Listen von Modellen¶
Genauso können Sie eine Response deklarieren, die eine Liste von Objekten ist.
Verwenden Sie dafür Pythons Standard typing.List (oder nur list in Python 3.9 und darüber):
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Item(BaseModel):
name: str
description: str
items = [
{"name": "Foo", "description": "There comes my hero"},
{"name": "Red", "description": "It's my aeroplane"},
]
@app.get("/items/", response_model=list[Item])
async def read_items():
return items
from typing import List
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Item(BaseModel):
name: str
description: str
items = [
{"name": "Foo", "description": "There comes my hero"},
{"name": "Red", "description": "It's my aeroplane"},
]
@app.get("/items/", response_model=List[Item])
async def read_items():
return items
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.
Das ist nützlich, wenn Sie die gültigen Feld-/Attribut-Namen von vorneherein nicht wissen (was für ein Pydantic-Modell notwendig ist).
In diesem Fall können Sie typing.Dict verwenden (oder nur dict in Python 3.9 und darüber):
from fastapi import FastAPI
app = FastAPI()
@app.get("/keyword-weights/", response_model=dict[str, float])
async def read_keyword_weights():
return {"foo": 2.3, "bar": 3.4}
from typing import Dict
from fastapi import FastAPI
app = FastAPI()
@app.get("/keyword-weights/", response_model=Dict[str, float])
async def read_keyword_weights():
return {"foo": 2.3, "bar": 3.4}
Zusammenfassung¶
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.