FastAPI ist ein modernes Python-Framework zum schnellen Erstellen von APIs — mit Type Hints, Validierung und automatischer OpenAPI-Dokumentation. Lerne die Grundlagen und Einsatzmöglichkeiten.
FastAPI ist ein Python-Framework, um Web-APIs schnell zu bauen — mit klarer Struktur und automatischer Dokumentation. Du schreibst kleine Funktionen (so genannte „Endpunkte“), die deklarieren, welche Daten deine API akzeptiert und zurückgibt, und FastAPI kümmert sich um die Web-Infrastruktur — Routing, Validierung und das Erzeugen von JSON-Antworten.
Eine API ist eine Sammlung von URLs, die es einem Software-Teil erlaubt, mit einem anderen zu sprechen.
Beispiel: Eine Wetter-App auf deinem Telefon könnte eine URL wie GET /weather?city=Berlin aufrufen. Der Server antwortet mit strukturierten Daten (meist JSON), etwa Temperatur und Vorhersage. Die App braucht keinen direkten Datenbankzugriff — sie fragt die API und zeigt das Ergebnis an.
FastAPI hilft dir, diese URLs und Antworten in Python zu erstellen.
Du musst kein Async-Experte sein, um zu starten; du kannst einfache Endpunkte schreiben und nach und nach fortgeschrittenere Muster übernehmen.
FastAPI verbreitete sich schnell, weil es vieles von der alltäglichen Reibung beim Aufbau von APIs in Python entfernt.
Konventionelle API-Projekte beginnen oft mit langsamer Einrichtung und viel „Plumbing“:
Die Kernfunktionen von FastAPI zielen direkt auf diese Probleme, sodass Teams mehr Zeit mit dem Design von Endpunkten verbringen und weniger mit Framework-Boilerplate kämpfen.
FastAPI setzt stark auf Python-Type-Hints. Wenn du deklarierst, dass ein Feld ein int, optional oder eine Liste von etwas ist, nutzt FastAPI diese Informationen zur Validierung von Eingaben und Formung der Ausgaben.
Das reduziert „stringly-typed“-Fehler (z. B. eine ID einmal als Text, einmal als Zahl zu behandeln) und fördert konsistentes Verhalten der Endpunkte. Es ist weiterhin Python, aber mit klareren Erwartungen, die in den Funktionssignaturen verankert sind.
Da das API-Schema aus dem Code abgeleitet wird, kann FastAPI interaktive Dokumentation automatisch generieren (OpenAPI + Swagger UI/ReDoc). Das ist für die Zusammenarbeit wichtig: Frontend-Entwickler, QA und Integratoren können Endpunkte erkunden, Requests testen und exakte Modelle sehen, ohne auf separate Dokumentationsarbeit warten zu müssen.
FastAPI löst kein schlechtes API-Design für dich. Du brauchst weiterhin gute Namensgebung, Versionierung, Fehlerbehandlung und Sicherheitsentscheidungen. Was es bietet, ist ein sauberer Weg von der Idee zur „wohl-definierten API“ mit weniger Überraschungen.
FastAPI wirkt unkompliziert, sobald du ein paar Kernideen verstanden hast. Du musst nicht die Interna auswendig lernen — erkenne einfach die Bausteine, die du jeden Tag nutzen wirst.
Ein Framework ist eine Sammlung von Werkzeugen und Konventionen, um eine API zu bauen, ohne bei Null anzufangen. FastAPI liefert die „Plumbing“ für übliche API-Aufgaben: Endpunkte definieren, Eingaben lesen, Ausgaben zurückgeben, Fehler behandeln und Code organisatorisch wartbar strukturieren.
Routing ordnet eine URL und HTTP-Methode einem Stück Python-Code zu.
Beispiel: GET /users könnte „Nutzer auflisten“ sein und POST /users „einen Nutzer anlegen“. In FastAPI definierst du Routen typischerweise mit Decorators wie @app.get(...) und @app.post(...), was es einfach macht, auf einen Blick zu sehen, was deine API anbietet.
Jeder API-Aufruf ist eine Request (was der Client sendet) und eine Response (was dein Server zurückliefert).
FastAPI hilft dir dabei:
/users/{id}), der Query-String (?page=2), Headern und dem Request-Body zu lesen200, 201, 404)FastAPI läuft auf ASGI, einem modernen Standard für Python-Webserver. Praktisch bedeutet das: FastAPI ist darauf ausgelegt, viele Verbindungen effizient zu handeln und kann Funktionen wie langlebige Verbindungen (z. B. WebSockets) unterstützen — ohne dass du dich um Low-Level-Netzwerkdetails kümmern musst.
Python-Type-Hints (z. B. str, int, list[Item]) sind in FastAPI nicht nur Dokumentation — sie sind eine zentrale Eingabe. FastAPI nutzt sie, um zu verstehen, welche Daten erwartet werden, eingehende Werte in die richtigen Typen zu konvertieren und vorhersehbare APIs zu erzeugen.
Pydantic-Modelle ermöglichen es dir, die Form von Daten (Felder, Typen, optionale Werte) an einer Stelle zu definieren. FastAPI verwendet diese Modelle, um eingehendes JSON zu validieren, ungültige Eingaben mit hilfreichen Fehlermeldungen abzulehnen und Ausgaben konsistent zu serialisieren — so verhält sich deine API zuverlässig, auch wenn Clients unsauberes JSON senden.
FastAPI-Apps bauen auf Endpunkten auf: ein URL-Pfad plus eine HTTP-Methode. Denk an einen Endpunkt als „was der Client anfragt“ und „wie er es anfragt“. Beispielsweise könnte ein Client GET /users aufrufen, um Nutzer aufzulisten, oder POST /users, um einen neuen Nutzer anzulegen.
Ein Pfad ist die Route, die Methode die Aktion:
GET /products → Daten abrufenPOST /products → Daten senden, um etwas zu erstellenPUT /products/123 → etwas ersetzen/aktualisierenDELETE /products/123 → etwas entfernenFastAPI trennt Daten, die Teil des Pfads sind, von optionalen „Filtern“ der Anfrage.
GET /users/42 → 42 ist die User-ID.? angehängt und meist optional.
GET /users?limit=10&active=true → limit und active steuern die Rückgabe.Wenn ein Client strukturierte Daten sendet (meist JSON), kommen diese in den Request-Body, häufig bei POST oder PUT.
Beispiel: POST /orders mit JSON wie { "item_id": 3, "quantity": 2 }.
FastAPI kann einfache Python-Objekte (z. B. dicts) zurückgeben, glänzt aber besonders, wenn du ein Response Model definierst. Dieses Modell wirkt als Vertrag: Felder werden konsistent geformt, zusätzliche Daten können herausgefiltert werden und Typen werden durchgesetzt. Ergebnis: sauberere APIs — Clients wissen, was sie erwarten können, und Überraschungsantworten, die Integrationen kaputtmachen, werden vermieden.
„Async“ (asynchron) ist eine Art, wie deine API viele Requests effizient handhaben kann, wenn viel Zeit mit Warten verbracht wird.
Stell dir einen Barista vor, der Bestellungen entgegennimmt. Wenn er stillstehen müsste, während die Espressomaschine läuft, würde er weniger Kunden bedienen. Besser ist: den Kaffee starten und dann die nächste Bestellung aufnehmen, während die Maschine arbeitet.
Async verhält sich ähnlich. Deine FastAPI-App kann eine Operation starten, die auf etwas Langsames wartet — z. B. einen Netzwerkaufruf oder eine Datenbankabfrage — und während sie darauf wartet, andere eingehende Requests bearbeiten.
Async ist besonders nützlich, wenn deine API viele I/O-gebundene Aufgaben ausführt — also Dinge, die Zeit mit Warten verbringen statt mit reiner Berechnung. Typische Beispiele:
Wenn deine Endpunkte oft auf solche Operationen warten, kann async Durchsatz und Reaktionsfähigkeit deutlich verbessern.
Async ist kein genereller Geschwindigkeitsboost für alles. Wenn dein Endpunkt hauptsächlich CPU-lastig ist — z. B. großes Bildskalieren, aufwändige Datenwissenschafts-Berechnungen oder starke Verschlüsselung — wird async die eigentliche Berechnung nicht beschleunigen. Dafür brauchst du andere Ansätze (Background-Worker, Process Pools oder horizontales Skalieren).
Du musst nicht alles umschreiben, um FastAPI zu nutzen. Reguläre (sync) Route-Funktionen funktionieren weiterhin. Viele Projekte mischen beide Stile: einfache Endpunkte synchron belassen und async def dort verwenden, wo es klar hilft (meist bei DB-Calls oder externen HTTP-Requests).
Validierung ist die Kontrollstation zwischen Außenwelt und deinem Code. Wenn eine API Eingaben akzeptiert (JSON-Body, Query-Params, Path-Params), willst du sicherstellen, dass die Daten vollständig, typgerecht und innerhalb sinnvoller Grenzen sind — bevor du in die DB schreibst, einen anderen Dienst aufrufst oder Business-Logik startest.
FastAPI setzt auf Pydantic-Modelle dafür. Du beschreibst einmal, wie „gute Daten“ aussehen, und FastAPI:
Wenn ein Client die falsche Datenform sendet, antwortet FastAPI mit 422 Unprocessable Entity und einer strukturierten Fehler-Antwort, die genau auf das Feld und den Grund hinweist. Das hilft Client-Entwicklern, Anfragen schnell zu korrigieren.
Hier ein kleines Modell mit Pflichtfeldern, Typen, Min/Max-Constraints und Formaten:
from pydantic import BaseModel, EmailStr, Field
class UserCreate(BaseModel):
email: EmailStr
age: int = Field(ge=13, le=120)
username: str = Field(min_length=3, max_length=20)
email muss vorhanden sein.age muss eine Ganzzahl sein.age ist auf 13–120 begrenzt.EmailStr erzwingt eine gültige E-Mail-Form.Die gleichen Modelle können auch die Ausgabe formen, sodass deine API-Antworten nicht versehentlich interne Felder ausplaudern. Du gibst Python-Objekte zurück; FastAPI (via Pydantic) wandelt sie in JSON mit den richtigen Feldnamen und Typen um.
Eine der nützlichsten Features von FastAPI ist, dass es API-Dokumentation automatisch für dich erzeugt — basierend auf dem bereits geschriebenen Code.
OpenAPI ist ein Standard, um eine API strukturiert zu beschreiben (meist JSON). Denk daran als Vertrag, der beschreibt:
GET /users/{id})Da es maschinenlesbar ist, können Tools damit Clients generieren, Requests validieren und Teams synchron halten.
FastAPI stellt zwei nutzerfreundliche Doku-Seiten automatisch bereit:
In einem üblichen FastAPI-Projekt findest du sie unter:
/docs (Swagger UI)/redoc (ReDoc)Wenn du Pfadparameter, Request-Modelle, Response-Modelle oder Validierungsregeln änderst, aktualisiert sich das OpenAPI-Schema (und damit die Doku-Seiten) automatisch. Kein separates "Docs-Pflegen" nötig.
Eine FastAPI-App kann winzig sein und trotzdem "echt" wirken. Du definierst ein Python-Objekt namens app, fügst ein paar Routen hinzu und startest einen lokalen Server, um es im Browser auszuprobieren.
Hier das kleinste nützliche Beispiel:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"message": "Hello, FastAPI"}
Das war's: eine Route (GET /), die JSON zurückgibt.
Um es etwas API-ähnlicher zu machen, speichern wir Items in einer Liste. Das ist keine Datenbank — Daten gehen beim Server-Neustart verloren — aber perfekt zum Lernen.
from fastapi import FastAPI
app = FastAPI()
items = []
@app.post("/items")
def create_item(name: str):
item = {"id": len(items) + 1, "name": name}
items.append(item)
return item
@app.get("/items")
def list_items():
return items
Du kannst jetzt:
POST /items?name=Coffee um ein Item hinzuzufügenGET /items um die Liste abzurufenEin gängiger Starter-Aufbau ist:
main.py (erstellt app und Routen)requirements.txt oder pyproject.toml (Dependencies)Üblicher Ablauf:
uvicorn main:app --reload)http://127.0.0.1:8000 öffnen und Endpunkte testenFastAPI-"Dependencies" sind gemeinsame Eingaben, die deine Endpunkte brauchen — z. B. eine DB-Session, der aktuell eingeloggte Nutzer, App-Settings oder wiederverwendete Query-Parameter. Statt diese Logik in jedem Route-Handler neu zu schreiben, definierst du sie einmal und FastAPI stellt sie dort bereit, wo sie gebraucht werden.
Eine Dependency ist meist eine Funktion (oder Klasse), die einen Wert zurückgibt, den dein Endpunkt verwendet. FastAPI ruft sie auf, erkennt anhand ihrer Parameter, was sie braucht, und injiziert das Ergebnis in deine Path-Operation-Funktion.
Das ist Dependency Injection in Aktion, aber du kannst es auch einfach so sehen: „Deklariere, was du brauchst, und FastAPI verkabelt es für dich.“
Ohne Dependencies würdest du vielleicht:
Mit Dependencies zentralisierst du diese Logik. Wenn du später änderst, wie eine DB-Session erstellt wird oder wie der aktuelle Nutzer geladen wird, änderst du eine Stelle — nicht dutzende Endpunkte.
page/limitDas konzeptionelle Muster sieht oft so aus:
from fastapi import Depends, FastAPI
app = FastAPI()
def get_settings():
return {"items_per_page": 20}
@app.get("/items")
def list_items(settings=Depends(get_settings)):
return {"limit": settings["items_per_page"]}
Du deklarierst die Dependency mit Depends(...), und FastAPI übergibt ihr Ergebnis an deinen Endpoint-Parameter. Das gleiche Muster funktioniert für komplexere Bausteine (wie get_db() oder get_current_user()), was deinen Code sauberer hält, je größer die API wird.
FastAPI sichert deine API nicht automatisch — du wählst das Schema und bindest es an deine Endpunkte. Die gute Nachricht: FastAPI stellt Bausteine (vor allem über das Dependency-System) bereit, die gängige Sicherheitsmuster einfach integrieren.
Authentifizierung beantwortet: „Wer bist du?“ Autorisierung beantwortet: „Was darfst du tun?“
Beispiel: Ein Nutzer kann authentifiziert sein (gültiger Login/Token), aber trotzdem nicht berechtigt sein, auf eine Admin-Route zuzugreifen.
X-API-Key). Rotation und Widerruf beachten.FastAPI unterstützt diese Muster über Hilfen wie fastapi.security und dokumentiert sie sauber im OpenAPI-Schema.
Wenn du Passwörter speicherst, niemand sollte sie im Klartext speichern. Nutze einen gesalzenen, langsamen Hash (z. B. bcrypt/argon2 über eine bewährte Bibliothek). Ziehe außerdem Rate-Limiting und Sperrmechanismen bei wiederholten Fehlversuchen in Betracht.
Sicherheit steckt in den Details: Token-Aufbewahrung, CORS-Settings, HTTPS, Secret-Management und korrekte Autorisierungsprüfungen auf jedem sensiblen Endpunkt. Betrachte eingebaute Helfer als Ausgangspunkt und prüfe deinen Ansatz per Reviews und Tests, bevor du ihn in Produktion nutzt.
Tests sind der Punkt, an dem FastAPIs "funktioniert bei mir" zu Vertrauen führt. Die gute Nachricht: FastAPI basiert auf Starlette, daher bekommst du starke Testing-Werkzeuge ohne großen Aufwand.
Unit-Tests prüfen kleine Einheiten: eine Berechnungsfunktion, eine Dependency, oder eine Service-Methode (oft mit Mocking der DB).
Integrationstests prüfen die API end-to-end: du rufst einen Endpunkt auf und überprüfst die volle HTTP-Antwort. Diese Tests fangen Routing-Fehler, Dependency-Wiring-Probleme und Validierungsfehler ein.
Ein gesundes Test-Setup hat meist mehr Unit-Tests (schnell) und weniger Integrationstests (höheres Vertrauen).
FastAPI-Apps lassen sich mit Starlette’s TestClient wie ein Client testen — Requests laufen in-process, kein laufender Server nötig.
from fastapi.testclient import TestClient
from app.main import app
client = TestClient(app)
def test_healthcheck():
r = client.get("/health")
assert r.status_code == 200
Teste die Dinge, auf die sich Nutzer und andere Systeme verlassen:
Nutze vorhersehbare Daten, isoliere externe Dienste (mock oder Test-DB) und vermeide geteilten Zustand zwischen Tests. Schnelle Tests werden ausgeführt; langsame Tests werden oft übersprungen.
Eine FastAPI-App online zu bringen heißt meist, den richtigen Runner zu wählen und ein paar Produktionsanforderungen zu ergänzen.
Wenn du lokal mit uvicorn main:app --reload startest, nutzt du eine Dev-Konfiguration: Auto-Reload, ausführliche Fehleranzeigen und Einstellungen, die Bequemlichkeit priorisieren.
In Produktion betreibst du Uvicorn meist ohne Reload, oft hinter einem Prozessmanager (z. B. Gunicorn mit Uvicorn-Workern) oder einem Reverse-Proxy. Ziel ist Stabilität: kontrollierte Neustarts, vorhersehbare Performance und sicherere Defaults.
Ein übliches Muster:
So bleibt ein Codebase in mehreren Umgebungen einsetzbar, ohne Dateien zu editieren.
Bevor du auf "Done" klickst, stell sicher, dass du:
/health für Monitoring und Load-BalancerWenn du von "lokal funktioniert" zu "bereit zur Auslieferung" wechselst, hilft es, wie du dein API-Contract erzeugst und managst, zu standardisieren. Manche Teams koppeln FastAPIs OpenAPI-Output an automatisierte Workflows — z. B. Client-Generierung, Request-Validierung in CI oder konsistente Deploys. Tools wie Koder.ai können in dieser Phase unterstützen: du beschreibst die API in Chat, iterierst Endpunkte und Modelle schnell und exportierst dann Code für einen normalen Review-/Deploy-Workflow.
FastAPI ist eine starke Wahl, wenn du eine saubere, moderne Methode suchst, REST-APIs in Python zu bauen — besonders wenn dir klare Request/Response-Modelle und vorhersehbares Verhalten beim Wachsen der API wichtig sind.
FastAPI eignet sich besonders für:
FastAPI ist nicht immer die einfachste Wahl:
FastAPI kann sehr schnell sein, aber die echte Geschwindigkeit hängt von Datenbankcalls, Netzwerk-Latenz und Business-Logik ab. Erwarte solide Durchsatzwerte und gute Latenz für typische API-Workloads — nimm aber nicht an, dass das Framework allein langsame I/O-Operationen oder ineffiziente Queries beheben wird.
Wenn FastAPI für dich passt, konzentriere dich als Nächstes auf Routing-Patterns, Pydantic-Modelle, Datenbankintegration, Background-Tasks und einfache Authentifizierung.
Ein praktischer Weg ist, mit einem kleinen Set an Endpunkten zu starten und dann mit wiederverwendbaren Dependencies und Tests zu erweitern, während die API wächst. Wenn du die anfängliche Scaffolding-Phase beschleunigen willst (Routen, Modelle und eine deployment-fähige Struktur), kannst du einen vibe-basierten Workflow nutzen — z. B. Endpunkte in einer „Planungsphase“ skizzieren und iterativ aus einem Spezifikations-Entwurf arbeiten. Das ist ein Bereich, in dem Tools wie Koder.ai helfen können: API-getriebene Apps prototypen, generierten Code verfeinern und dann exportieren, um ihn wie ein normales Projekt zu betreiben.
FastAPI ist ein Python-Webframework zum Erstellen von APIs mit minimalem Boilerplate. Du schreibst Endpunkt-Funktionen (z. B. @app.get("/users")) und FastAPI kümmert sich um Routing, Request-Parsing, Validierung und JSON-Antworten.
Ein großer Vorteil ist, dass deine Type Hints und Pydantic-Modelle als expliziter Vertrag dafür dienen, was die API akzeptiert und zurückgibt.
Eine API ist eine Sammlung von URLs (Endpunkten), die andere Software aufrufen kann, um Daten auszutauschen.
Zum Beispiel könnte ein Client Wetterdaten mit GET /weather?city=Berlin anfordern, und der Server antwortet mit strukturiertem JSON. Der Client braucht keinen direkten Datenbankzugriff — er nutzt einfach die API-Antwort.
Routing ordnet eine HTTP-Methode + Pfad einer Python-Funktion zu.
In FastAPI nutzt man typischerweise Decorators:
@app.get("/items") für Lese-Operationen@app.post("/items") für Erstellen@app.put("/items/{id}") zum Aktualisieren/ErsetzenPath-Parameter sind Teil der URL-Struktur und identifizieren normalerweise eine bestimmte Ressource (erforderlich).
GET /users/42 → 42 ist ein Path-ParameterQuery-Parameter werden nach ? angehängt und sind meist optionale Filter oder Steuerungswerte.
Pydantic-Modelle definieren Form und Regeln deiner Daten (Typen, erforderliche Felder, Constraints). FastAPI nutzt sie um:
Wenn die Validierung fehlschlägt, antwortet FastAPI typischerweise mit 422 Unprocessable Entity und Details, welches Feld warum falsch ist.
FastAPI generiert automatisch ein OpenAPI-Schema aus deinen Endpunkten, Type Hints und Modellen.
Du bekommst in der Regel interaktive Docs kostenlos:
/docs/redocDa das Schema aus dem Code entsteht, bleiben die Dokumentationen synchron, wenn du Parameter oder Modelle änderst.
Verwende async def, wenn dein Endpunkt viel Zeit mit Warten auf I/O verbringt (Datenbankaufrufe, externe HTTP-Anfragen, Dateizugriffe).
Nutze reguläres def, wenn:
Es ist üblich, sync- und async-Endpunkte in derselben App zu mischen.
Dependencies sind wiederverwendbare Bausteine, die FastAPI über Depends() in Endpunkte injiziert.
Sie werden oft verwendet für:
So reduzierst du Redundanz und zentralisierst Querschnitts-Logik, damit Änderungen nur an einer Stelle nötig sind.
FastAPI sichert deine API nicht automatisch — du wählst ein Schema und bindest es ein. Häufige Muster sind:
Wichtig sind außerdem Grundlagen: Passwörter nie im Klartext speichern (salted, langsamer Hash wie bcrypt/argon2), HTTPS verwenden und CORS-Einstellungen für Browser-Clients prüfen.
Zum Testen kannst du FastAPI/Starlette’s TestClient nutzen, um deine API in-process aufzurufen (kein Server nötig).
Wichtige Prüfungen:
Beim Deploy: einen ASGI-Server betreiben (z. B. Uvicorn, eventuell hinter Gunicorn oder Reverse-Proxy) und Produktionsaspekte wie Logging, Health-Checks (), Timeouts und konfigurationsbasierte Einstellungen hinzufügen.
@app.delete("/items/{id}") zum EntfernenSo wird die Oberfläche deiner API direkt im Code ersichtlich.
GET /users?limit=10&active=true → limit, active sind Query-Parameter/health