Fragen Sie fünf Entwickler, was Flask ist, und Sie erhalten fünf überzeugte Antworten – die meisten davon nur zur Hälfte richtig. Worum es eigentlich geht: Ein Flask-Python-Projekt kann innerhalb eines Nachmittags von einem leeren Verzeichnis zu einer funktionierenden API heranwachsen, um dann – ohne bewusste Entscheidungen zu Struktur, Validierung und Deployment – still und leise zu dem System zu werden, das niemand mehr anfassen möchte. Schnell gestartet. Teuer vernachlässigt.
Dieser Leitfaden deckt beide Seiten dieser Geschichte ab. Wenn Sie Entwickler sind, bauen wir gemeinsam Schritt für Schritt eine funktionierende REST-API auf: CRUD-Endpunkte, eine SQLite-Datenbank via SQLAlchemy, Request-Validierung und Fehlerbehandlung, OpenAPI-Dokumentation sowie eine Projektstruktur, die auch bei wachsenden Anforderungen Bestand hat.
Wenn Sie CTO oder Engineering Lead sind und Python Flask gegen FastAPI abwägen, springen Sie direkt zum Abschnitt über Produktionsreife und Entscheidungshilfen für Führungskräfte. Diese Bereiche sind auf Ihre Bedürfnisse zugeschnitten: Team-Expertise, Lieferrisiken und die tatsächlichen Wartungskosten.
Flask ist ein leichtgewichtiges Python-Webframework, mit dem sich APIs und Webanwendungen erstellen lassen, indem HTTP-Routen auf Funktionen abgebildet werden, die JSON oder HTML zurückgeben. Es handelt sich um ein WSGI-Framework, wobei WSGI (Web Server Gateway Interface) schlicht die Standardschnittstelle zwischen Python-Webanwendungen und den Webservern ist, auf denen sie laufen. Das offizielle Flask-Dokumentation nennt es ein Mikroframework, was zutreffend und gleichzeitig ein wenig irreführend ist.
„Mikro“ beschreibt den Kern, nicht den Anspruch. Flask liefert Ihnen das Fahrgestell, nicht das fertige Auto: Motor, Sitze und Armaturenbrett wählen Sie selbst aus einem Teilekatalog, den die Community seit 2010 stetig erweitert. Genau diese Freiheit macht den Reiz aus (und birgt, wie wir sehen werden, auch das Risiko).
Python bietet verschiedene Frameworks an, darunter Tornado, Pyramid, Django und FastAPI. Falls Sie sich noch bei der Wahl der Sprache unsicher sind, erläutert unser Überblick über die Vorteile von Python , warum sie im Backend- und Datenbereich dominiert.
Ist Flask noch eine gängige Wahl? Absolut. In der Stack Overflow Developer Survey 2025gaben etwa 15 % der Befragten an, Flask zu verwenden, womit es neben FastAPI zu den meistgenutzten Webframeworks überhaupt zählt. Auch der Teilekatalog ist ausgereift: Flask-SQLAlchemy für Datenbanken, Flask-Login und Flask-JWT-Extended für die Authentifizierung, Flask-Migrate für Schema-Migrationen und Flask-Limiter für Rate Limiting. Allesamt seit Jahren gepflegt.
Aus der Audit-Praxis von IC: Die Freiheit von Flask ist ein zweischneidiges Schwert. Sie sorgt dafür, dass die ersten Wochen eines Flask-Python-Projekts schnell vorangehen, ist aber auch der häufigste Grund, warum wir ein Jahr später gebeten werden, einen verstrickten Code zu entwirren. Das Framework hält drei Entwickler nicht davon ab, drei verschiedene Strukturen innerhalb derselben Anwendung zu entwerfen. Nichts kann das verhindern – außer das Team selbst.
API steht für Application Programming Interface – die Schnittstelle, über die Systeme miteinander kommunizieren. Eine REST-API (Representational State Transfer) ist ein Architekturstil für diese Kommunikation, der auf zustandslosen Anfragen über Standard-HTTP-Methoden basiert und Client- sowie Server-Logik strikt voneinander trennt.
In der Praxis tauscht eine REST-API JSON-Daten aus und ordnet Endpunkte vier Verben zu: Erstellen (POST), Lesen (GET), Aktualisieren (PUT oder PATCH) und Löschen (DELETE). Zusammen werden diese als CRUD-Operationen bezeichnet, und die API, die Sie in diesem Leitfaden erstellen, implementiert alle vier für eine einzelne Entität. REST ist übrigens nicht der einzige Architekturstil. Wenn Ihre Dienste intern sind und eine geringe Latenz erfordern, hilft unser Vergleich zwischen gRPC und REST dabei zu verstehen, wann sich ein binäres Protokoll lohnt.
Aus der Audit-Praxis von IC: Das häufigste Designproblem bei REST, auf das wir stoßen, ist kein fehlender Endpunkt. Es ist Inkonsistenz: Eine Route liefert snake_case, eine andere camelCase; eine verpackt Fehler in JSON, eine andere liefert eine einfache HTML-Seite. Sich vor dem ersten Endpunkt auf diese Konventionen zu einigen, kostet eine Stunde und spart Wochen.
Jede Flask-API benötigt das gleiche Fundament, bevor die erste Zeile Anwendungscode geschrieben wird. Legen wir los.
Sie müssen Python installiert haben. Der hier verwendete Code setzt Python 3 voraus; falls Sie Windows nutzen oder Python 2 benötigen, folgen Sie der Flask-Installationsanleitung.
Erstellen Sie zunächst ein Verzeichnis für das Projekt. Führen Sie an dem Ort, an dem das Projekt gespeichert werden soll, die folgenden Befehle in der Shell aus:
mkdir flask_api
cd flask_api
Wir haben das Projektverzeichnis erstellt und sind in dieses gewechselt. Bevor Sie etwas installieren, erstellen Sie eine virtuelle Umgebung:
python3 -m venv venv
Dadurch wird ein Ordner namens venv in Ihrem Projekt erstellt. Aktivieren Sie ihn mit folgendem Befehl:
source venv/bin/activate
# On Windows:
venv\Scripts\activate
Ab jetzt verwendet jedes Python-Programm, das Sie ausführen, die venv-Umgebung. Wenn Sie eine IDE verwenden, verweisen Sie diese auf dieselbe Umgebung (eine klassische Fehlerquelle, wenn es im Terminal funktioniert, aber nicht in der IDE).
Woher wissen Sie, dass sie aktiv ist? Prüfen Sie den linken Bereich der Konsole: Wenn der Name der Umgebung in Klammern steht, ist alles bereit. Um sie später zu deaktivieren, führen Sie Folgendes aus:
deactivate
Eine typische Python-Flask-API wird in sechs Schritten erstellt:
Dieser Leitfaden folgt dieser Reihenfolge, da wir sie auch bei Kundenprojekten anwenden. So bleiben Backend-Services vom ersten Commit an strukturiert und nicht erst nach dem fünfzehnten Refactoring.
.webp)
Eine API, die Daten in einer Python-Liste speichert, vergisst alles, sobald der Server neu startet. Echte Anwendungen speichern Daten dauerhaft. In diesem Abschnitt verbinden wir daher die Flask-API mit einer Datenbank unter Verwendung von SQLite und SQLAlchemy.
SQLite ist eine leichtgewichtige Datenbank, die keinen separaten Server benötigt, was sie ideal für Tutorials und kleine Anwendungen macht. Perfekt für heute. Nicht unbedingt für den Tag der Veröffentlichung.
Aus der Audit-Praxis von IC: Fast jedes Flask-Projekt, das wir übernehmen, begann mit SQLite „nur für den Moment“. Das ist ein guter Ausgangspunkt, vorausgesetzt, die SQLAlchemy-Modelle sind so geschrieben, als stünde PostgreSQL bereits vor der Tür. Denn in der Produktion ist das meistens der Fall.
Installieren Sie die erforderlichen Abhängigkeiten:
pip install Flask Flask-SQLAlchemy
Wenn Sie Abhängigkeiten über eine requirements.txt -Datei verwalten, fügen Sie Folgendes hinzu:
Flask
Flask-SQLAlchemy
In diesem Setup ist SQLAlchemy der Object Relational Mapper. Ein ORM (Object Relational Mapper) ermöglicht es Ihnen, Datenbankeinträge wie gewöhnliche Python-Objekte zu behandeln, anstatt rohes SQL schreiben zu müssen; die SQLAlchemy-Dokumentation deckt das gesamte Spektrum ab. Flask-SQLAlchemy bindet es in Flask ein.
Verweisen Sie Flask auf die SQLite-Datenbank, indem Sie den Verbindungs-String definieren:
from flask import Flask, request, jsonify
from flask_sqlalchemy import SQLAlchemy
app = Flask(__name__)
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///items.db"
db = SQLAlchemy(app)
Dies erstellt eine lokale SQLite-Datenbankdatei namens items.db im Projektverzeichnis.
Erstellen Sie ein Modell, das die Struktur der Datenbanktabelle repräsentiert:
class Item(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(80), nullable=False)
price = db.Column(db.Float, nullable=False)
def to_dict(self):
return {"id": self.id, "name": self.name, "price": self.price}
Das Item -Modell definiert drei Felder: id (eindeutiger Bezeichner), name und Preis. Die to_dict() -Methode wandelt das Datenbankobjekt in ein JSON-serialisierbares Dictionary um.
Bevor Sie die API starten, erstellen Sie die Tabellen mit SQLAlchemy:
with app.app_context():
db.create_all()
Dieser Endpunkt gibt alle in der Datenbank gespeicherten Elemente zurück:
@app.route("/items", methods=["GET"])
def get_items():
items = Item.query.all()
return jsonify([item.to_dict() for item in items])
Dieser Endpunkt liest den JSON-Request-Body, validiert die Eingabe, erstellt einen Datenbankeintrag und gibt das erstellte Element zurück:
@app.route("/items", methods=["POST"])
def create_item():
data = request.get_json()
if not data or "name" not in data or "price" not in data:
return jsonify({"error": "Both 'name' and 'price' are required."}), 400
item = Item(name=data["name"], price=data["price"])
db.session.add(item)
db.session.commit()
return jsonify(item.to_dict()), 201
Dieser Endpunkt ruft ein spezifisches Element anhand seiner ID ab:
@app.route("/items/<int:item_id>", methods=["GET"])
def get_item(item_id):
item = Item.query.get_or_404(item_id)
return jsonify(item.to_dict())Wenn das Element nicht existiert, gibt Flask automatisch einen 404-Fehlerzurück. Es ist kein zusätzlicher Code erforderlich.
Dieser Endpunkt aktualisiert ein bestehendes Element. Es werden nur die bereitgestellten Felder geändert.
@app.route("/items/<int:item_id>", methods=["PUT"])
def update_item(item_id):
item = Item.query.get_or_404(item_id)
data = request.get_json() or {}
if "name" in data:
item.name = data["name"]
if "price" in data:
item.price = data["price"]
db.session.commit()
return jsonify(item.to_dict())
Dieser Endpunkt entfernt das angegebene Element aus der Datenbank:
@app.route("/items/<int:item_id>", methods=["DELETE"])
def delete_item(item_id):
item = Item.query.get_or_404(item_id)
db.session.delete(item)
db.session.commit()
return jsonify({"message": f"Item {item_id} deleted."})
Starten Sie den Flask-Entwicklungsserver:
python app.py
# or, with the Flask CLI:
flask --app app run --debugIhre API ist nun lokal verfügbar.
Ein neues Element erstellen, die Anfrage:
curl -X POST http://localhost:5000/items \
-H "Content-Type: application/json" \
-d '{"name": "Keyboard", "price": 49.9}'
Die Antwort:
{
"id": 1,
"name": "Keyboard",
"price": 49.9
}
Alle Elemente abrufen, die Antwort:
[
{
"id": 1,
"name": "Keyboard",
"price": 49.9
}
]
Da Listen bei einem Neustart Daten verlieren, nicht zwischen Anwendungsinstanzen geteilt werden können und sich nicht effizient abfragen lassen. Eine Datenbank wie SQLite bietet Ihrer API einen persistenten, abfragbaren Speicher: das Verhalten, das ein echter Backend-Dienst benötigt.
Für Produktionssysteme wechseln Teams in der Regel zu PostgreSQL, MySQL oder MongoDB. Die grundlegende Struktur der Flask-API bleibt dabei gleich.
Stellen Sie sich eine API in einer einzigen Datei wie ein Einzimmerapartment vor. Alles ist in Reichweite, es ist kein Grundriss erforderlich, und genau das ist bei einem kleinen Projekt der Sinn der Sache:
flask_api/
├── app.py
├── models.py
├── routes.py
├── requirements.txt
└── items.dbIn dieser Struktur app.py erstellt die Flask-Anwendung und konfiguriert die Erweiterungen, models.py definiert die SQLAlchemy-Modelle, routes.py enthält die Endpunkte, requirements.txt listet die Abhängigkeiten auf und items.db ist die Entwicklungsdatenbank.
Dieses Layout eignet sich für kleine APIs, Prototypen und Lernprojekte. Aber niemand gründet eine Familie in einem Einzimmerapartment, und niemand sollte ein Produkt in einer einzigen Datei entwickeln.
app.py erstellt die Flask-Anwendung, konfiguriert die Datenbank und registriert die Routen.
from flask import Flask
from models import db
import routes
app = Flask(__name__)
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///items.db"
db.init_app(app)
app.register_blueprint(routes.bp)
with app.app_context():
db.create_all()
if __name__ == "__main__":
app.run(debug=True)models.py definiert das Datenbankmodell.
from flask_sqlalchemy import SQLAlchemy
db = SQLAlchemy()
class Item(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(80), nullable=False)
price = db.Column(db.Float, nullable=False)
def to_dict(self):
return {"id": self.id, "name": self.name, "price": self.price}routes.py enthält die API-Endpunkte.
from flask import Blueprint, request, jsonify
from models import db, Item
bp = Blueprint("items", __name__)
@bp.route("/items", methods=["GET"])
def get_items():
return jsonify([item.to_dict() for item in Item.query.all()])
# ... remaining CRUD endpoints as in snippets 11-14, using @bp.routeDurch die Aufteilung der Anwendung auf mehrere Dateien bleiben Verantwortlichkeiten klar getrennt und der Code übersichtlich. Wenn Sie später Authentifizierung, Benutzer oder Bestellungen hinzufügen, erweitern Sie die Struktur, anstatt das Projekt neu zu schreiben.
Größere Python-Flask-Anwendungen benötigen ein Haus statt einer Wohnung: Pakete anstelle von Dateien auf oberster Ebene, mit einem eigenen Bereich für jeden Aufgabenbereich.
flask_api/
├── app/
│ ├── __init__.py
│ ├── models/
│ │ └── item.py
│ ├── routes/
│ │ └── items.py
│ └── schemas/
│ └── item.py
├── requirements.txt
└── run.pyIn dieser Architektur enthält das app-Paket die Hauptlogik der Anwendung, models/ definiert Datenbankmodelle, routes/ gruppiert Endpunkte nach Ressourcen und run.py startet die Anwendung. Der schemas/ Ordner übernimmt die Validierung von Anfragen und Antworten mithilfe von Marshmallow, einer Python-Bibliothek zur Definition von Schemas, die eingehende Daten validieren und ausgehende Antworten serialisieren.
Der Vorteil liegt auf der Hand: Endpunkte bleiben nach Ressourcen organisiert, Funktionen wie Authentifizierung oder Hintergrundprozesse lassen sich sauber integrieren und mehrere Entwickler können parallel arbeiten, ohne sich gegenseitig in die Quere zu kommen.
Bewährte Methode: Beginnen Sie mit einer einfachen Struktur und erweitern Sie diese erst, wenn die Anwendung wächst. Für kleine Projekte reichen einige wenige, klar benannte Dateien aus. Bei größeren Flask-APIs sorgt das paketbasierte Layout dafür, dass der Wartungsaufwand gering bleibt.
Ein Blueprint ist ein Objekt, das einem Flask-Anwendungsobjekt sehr ähnlich ist, mit dem Unterschied, dass es die bestehende Anwendung erweitert, anstatt eine neue zu erstellen. Blueprints sind das Mittel, um eine Flask-API in Abschnitte zu unterteilen: nach Ressourcen, API-Versionen oder Diensten.
Wann braucht man sie also wirklich? Früher, als Sie denken.
Aus der Audit-Praxis von IC: Eine einzelne Routen-Datei beginnt genau in dem Moment Merge-Konflikte anzuhäufen, in dem ein zweiter Entwickler hinzukommt oder eine zweite Ressource erscheint. Das ist das Signal, auf Blueprints umzusteigen. Nicht erst, wenn sich die Datei irgendwann „zu lang“ anfühlt.
Lassen Sie uns den obigen Code in einen Blueprint umwandeln und in die Hauptanwendung laden. Erstellen Sie einen neuen Ordner namens blueprints, und darin einen Ordner sowie eine Datei für den Items-Blueprint:
from flask import Blueprint, request, jsonify
from models import db, Item
items_bp = Blueprint("items", __name__, url_prefix="/items")
@items_bp.route("", methods=["GET"])
def get_items():
return jsonify([item.to_dict() for item in Item.query.all()])
# ... remaining CRUD endpoints moved here unchanged
Jetzt muss app.py nur noch den erstellten Blueprint laden und am Anwendungsobjekt registrieren:
from blueprints.items.routes import items_bp
app.register_blueprint(items_bp)Gleiche Endpunkte, bessere Struktur. Genau das sorgt dafür, dass eine wachsende Flask-Python-Anwendung wartbar bleibt.
Die Validierung ist der Türsteher Ihrer API. Sie prüft die Anmeldedaten am Eingang, damit Sie später keine fehlerhaften Daten aus der Datenbank ziehen müssen, wenn diese sich bereits mit Ihren Berichten „angefreundet“ haben. Eine gut konzipierte Flask-API validiert eingehende Daten, gibt klare Fehlermeldungen zurück und verwendet die korrekten HTTP-Statuscodes.
Aus der Audit-Praxis von IC: Bei den Produktionsvorfällen, zu deren Diagnose wir hinzugezogen werden, ist eine fehlende Anfragevalidierung eine der häufigsten Grundursachen. Fehlerhafte Daten gelangen unbemerkt ins System und tauchen Wochen später als Reporting-Fehler auf, deren Ursprung nur mit hohem Aufwand zurückverfolgt werden kann.
Wenn ein Client Daten sendet, sollte der Server überprüfen, ob die erforderlichen Felder vorhanden und korrekt formatiert sind. Das Erstellen eines neuen Elements erfordert beispielsweise sowohl einen Namen als auch einen Preis.
Hier ist ein einfaches Beispiel für eine Validierung:
@app.route("/items", methods=["POST"])
def create_item():
data = request.get_json()
if not data or "name" not in data or "price" not in data:
return jsonify({"error": "Both 'name' and 'price' are required."}), 400
item = Item(name=data["name"], price=data["price"])
db.session.add(item)
db.session.commit()
return jsonify(item.to_dict()), 201Die API prüft, ob der Request-Body JSON enthält und ob die erforderlichen Felder vorhanden sind. Schlägt die Validierung fehl, wird eine 400 Bad Request -Antwort zurückgegeben. Der Türsteher weist den Einlass höflich und im JSON-Format ab.
Statuscodes teilen dem Client mit, ob eine Anfrage erfolgreich war oder fehlgeschlagen ist. Die gängigsten in REST-APIs sind:
Der richtige Code ermöglicht es API-Nutzern, Antworten programmatisch zu verarbeiten, anstatt Fehlermeldungen im Klartext zu parsen.
Wenn ein Client eine Ressource anfordert, die nicht existiert, sollte die API einen 404-Fehlerzurückgeben. Flask-SQLAlchemy bietet hierfür eine praktische Hilfsfunktion:
@app.route("/items/<int:item_id>", methods=["GET"])
def get_item(item_id):
item = Item.query.get_or_404(item_id)
return jsonify(item.to_dict())
Wenn das Element nicht existiert, gibt Flask automatisch eine Antwort wie diese zurück:
{
"error": "Resource not found"
}Keine leeren Antworten, keine irreführenden Informationen.
Definieren Sie in größeren Anwendungen globale Fehler-Handler, die bei häufigen Fehlern konsistente Antworten liefern:
@app.errorhandler(400)
def bad_request(error):
return jsonify({"error": "Bad request"}), 400
@app.errorhandler(404)
def not_found(error):
return jsonify({"error": "Resource not found"}), 404
@app.errorhandler(500)
def internal_error(error):
return jsonify({"error": "Internal server error"}), 500Dank dieser Handler gibt die API stets strukturiertes JSON anstelle von standardmäßigen HTML-Fehlerseiten zurück.
Wenn ein Client versucht, ein Element ohne die erforderlichen Felder zu erstellen, könnte die API Folgendes zurückgeben:
{
"error": "Both 'name' and 'price' are required."
}Klare Fehlermeldungen ermöglichen es Entwicklern, ihre eigenen Fehler zu diagnostizieren, ohne Ihren Quellcode lesen zu müssen. Ihr zukünftiges Ich zählt übrigens auch zu diesen Entwicklern.
Zusammen verhindern sie, dass ungültige Daten in die Datenbank gelangen, machen Antworten vorhersehbar und ermöglichen eine schnelle Fehlersuche. Dies ist Standard in der modernen API-Entwicklung und bei einem Flask-Dienst in der Produktion unverzichtbar.
Moderne APIs sollten maschinenlesbare Dokumentationen bereitstellen, damit Entwickler Endpunkte, Anfrageformate und Antworten verstehen können, ohne den Code lesen zu müssen. Der dominierende Standard ist OpenAPI, das HTTP-APIs in einem Format beschreibt, das von Tools automatisch interpretiert werden kann.
In Flask ist der bequemste Weg flask-smorest, eine Bibliothek, die Flask mit OpenAPI 3, Anfragvalidierung und automatischer Swagger-UI-Dokumentation verbindet.
Installieren Sie die erforderlichen Pakete:
pip install flask-smorest marshmallowOder fügen Sie sie Ihrer requirements.txt -Datei hinzu:
flask-smorest
marshmallowIn diesem Setup generiert flask-smorest die OpenAPI-Dokumentation und verwaltet das API-Routing, während marshmallow (im Abschnitt zur Struktur eingeführt) die Anfragvalidierung und die Serialisierung der Antworten übernimmt.
Konfigurieren Sie die Anwendung zur Generierung der Dokumentation, bevor Sie Endpunkte erstellen:
from flask import Flask
from flask_smorest import Api
app = Flask(__name__)
app.config["API_TITLE"] = "Items API"
app.config["API_VERSION"] = "v1"
app.config["OPENAPI_VERSION"] = "3.0.3"
app.config["OPENAPI_URL_PREFIX"] = "/"
app.config["OPENAPI_SWAGGER_UI_PATH"] = "/swagger-ui"
app.config["OPENAPI_SWAGGER_UI_URL"] = "https://cdn.jsdelivr.net/npm/swagger-ui-dist/"
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///items_smorest.db"Zu den wichtigsten Einstellungen gehören API_TITLE (der Name Ihrer API), API_VERSION, OPENAPI_VERSION (die Spezifikationsversion) und OPENAPI_SWAGGER_UI_PATH (der Pfad, unter dem die interaktive Dokumentation bereitgestellt wird, zum Beispiel /swagger-ui).
Mit flask-smorest wird die Struktur der Daten, die Ihre API akzeptiert und zurückgibt, über Marshmallow-Schemas definiert. Erstellen Sie ein Schema, das ein Element beschreibt:
from marshmallow import Schema, fields
class ItemSchema(Schema):
id = fields.Int(dump_only=True)
name = fields.Str(required=True)
price = fields.Float(required=True)Ein Schema erfüllt vier Aufgaben: Es validiert eingehende Anfragen, dokumentiert das erwartete Format, serialisiert Antworten und generiert präzise OpenAPI-Ausgaben. Deshalb empfehlen wir den „Schemas-first“-Ansatz.
Erstellen Sie Endpunkte mithilfe eines Blueprint, um zusammengehörige Routen zu gruppieren:
from flask_smorest import Blueprint
blp = Blueprint("items", __name__, url_prefix="/items", description="Operations on items")Jeder Blueprint wird zu einem Abschnitt in der generierten Dokumentation.
Implementieren Sie nun Endpunkte zum Erstellen und Abrufen von Elementen:
@blp.route("/")
class ItemList(MethodView):
@blp.response(200, ItemSchema(many=True))
def get(self):
return Item.query.all()
@blp.arguments(ItemSchema)
@blp.response(201, ItemSchema)
def post(self, new_data):
item = Item(**new_data)
db.session.add(item)
db.session.commit()
return itemHierbei @blp.arguments validiert den eingehenden Request-Body, @blp.response dokumentiert und serialisiert die Ausgabe, und MethodView gruppiert mehrere HTTP-Methoden unter einer Route. Die Decorator aktualisieren die OpenAPI-Dokumentation automatisch.
Registrieren Sie den Blueprint bei der API-Instanz, um die Endpunkte zu aktivieren:
api.register_blueprint(blp)
Öffnen Sie bei laufender Anwendung die Swagger-UI-URL in Ihrem Browser:
http://localhost:5000/swagger-uiÜber die interaktive Swagger-UI können Sie alle Endpunkte einsehen, Parameter prüfen, Anfragen direkt aus dem Browser testen und Schemas erkunden. Da OpenAPI ein branchenweiter Standard ist, dient dieselbe Spezifikation zudem als Grundlage für die Client-Generierung und automatisierte API-Testtools.
Ist der integrierte Flask-Server für den Produktivbetrieb geeignet? Nein. Er ist ausschließlich für die Entwicklung gedacht. Für produktive Umgebungen benötigen Sie einen WSGI-Server und einen Webserver, um echten Datenverkehr zuverlässig zu bewältigen.
Aus der Audit-Praxis von IC: Ein wiederkehrender Befund bei unseren Überprüfungen ist, dass der Flask-Entwicklungsserver in die Produktion übernommen wurde, weil er „funktioniert hat“. Das tut er auch – bis der erste gleichzeitige Datenverkehr eintrifft.
Ein gängiges Deployment-Setup kombiniert Gunicorn oder uWSGI als WSGI-Server mit Nginx als Reverse Proxy, gehostet auf einer Cloud- oder Container-Plattform wie AWS, Azure oder Google Cloud. Gunicorn und uWSGI sind produktionsreife WSGI-Server: Programme, die mehrere Instanzen Ihrer Python-Anwendung ausführen und eingehende Anfragen verwalten – genau die Aufgabe, für die der Single-Threaded-Entwicklungsserver nie konzipiert wurde.
Führen Sie eine Flask-Anwendung beispielsweise mit Gunicorn in der Produktion so aus:
gunicorn -w 4 "app:app"In diesem Befehl startet -w 4 vier Worker-Prozesse und app:app referenziert das Flask-Anwendungsobjekt.
In modernen Umgebungen werden Flask-APIs üblicherweise als Docker-Containerbereitgestellt, was die Skalierung, das Umgebungsmanagement und die kontinuierliche Bereitstellung vereinfacht. Wenn Ihr Team Kubernetes einsetzt, behandelt unser Leitfaden zum Aufbau einer Kubernetes-optimierten CI/CD-Pipeline , wie containerisierte APIs wie diese vom Commit bis in den Cluster gelangen.
Die meisten produktiven APIs beschränken den Zugriff, sodass nur autorisierte Benutzer oder Dienste geschützte Endpunkte erreichen können. Die gängigen Ansätze sind API-Schlüssel für einfachen Dienst-zu-Dienst-Zugriff, JWT (JSON Web Tokens) für die Benutzerauthentifizierung und OAuth 2.0 für Integrationen von Drittanbietern.
JWT-basierte Authentifizierung ist das Muster, das wir bei Flask-APIs am häufigsten verwenden. Ein Benutzer meldet sich mit Anmeldedaten an, der Server stellt ein signiertes Token aus und der Client präsentiert dieses Token bei jeder Anfrage im Authorization -Header (der Name des Headers behält seine amerikanische Schreibweise bei, da der HTTP-Standard dies so definiert).
Beispiel-Header:
Authorization: Bearer <your-jwt-token>
Erweiterungen wie Flask-JWT-Extended übernehmen die Token-Verwaltung und den Routenschutz, sodass Sie keine eigene Kryptografie implementieren müssen. Mit einer eingerichteten Autorisierung erreichen nur berechtigte Clients die API, sensible Daten bleiben geschützt und die Nutzung kann pro Client überwacht werden.
Aus der Audit-Praxis von IC: Wir betrachten die Authentifizierung als Teil der ursprünglichen Architektur und nicht als nachträgliche Härtungsmaßnahme. Sie nachträglich in Dutzende bestehender Endpunkte zu integrieren, ist durchweg teurer, als sie von der ersten Route an mit einzuplanen.
Tutorials enden meist bei „die API funktioniert“. Bevor wir bei Imaginary Cloud eine Flask-API für die Produktion freigeben, muss sie die IC-Checkliste für Produktionsreife bestehen – dieselbe Prüfung, die wir auch bei unseren Technischen und UX-Auditsanwenden.
Fünf Punkte dieser Checkliste fehlen in den meisten Flask-Anleitungen:
Gehen wir sie nacheinander durch.
Flask enthält einen Test-Client, der Ihre Endpunkte aufruft, ohne einen Server zu starten. Er lässt sich hervorragend mit pytestkombinieren. Ein minimaler Test sieht so aus:
import pytest
from app import create_app, db
@pytest.fixture
def client():
app = create_app(testing=True)
with app.test_client() as client:
with app.app_context():
db.create_all()
yield client
def test_create_item(client):
response = client.post("/items", json={"name": "Keyboard", "price": 49.9})
assert response.status_code == 201
assert response.get_json()["name"] == "Keyboard"Unit-Tests decken einzelne Funktionen ab; Integrationstests wie der obige prüfen den gesamten Request-Zyklus, vom Routing über die Validierung und Datenbankanbindung bis hin zur Serialisierung. Führen Sie beide bei jedem Commit in Ihrer CI-Umgebung gegen eine temporäre Datenbank aus.
Datenbank-URLs, JWT-Signaturschlüssel und Zugangsdaten für Drittanbieter dürfen niemals fest im Code hinterlegt oder in die Versionsverwaltung eingecheckt werden. Lesen Sie diese stattdessen aus Umgebungsvariablen aus. Lokal sorgt eine .env -Datei, die mit python-dotenv geladen wird, für Komfort:
import os
from dotenv import load_dotenv
load_dotenv()
SQLALCHEMY_DATABASE_URI = os.environ["DATABASE_URL"]
JWT_SECRET_KEY = os.environ["JWT_SECRET_KEY"]Fügen Sie .env zu Ihrer .gitignorehinzu. In der Produktion sollten Sie dieselben Variablen über den Secret-Manager Ihrer Plattform (AWS Secrets Manager, Azure Key Vault oder Kubernetes Secrets) bereitstellen.
Ein Rate-Limiting schützt die API vor Missbrauch und vor gut gemeinten Clients, die in Wiederholungsschleifen feststecken. Flask-Limiter fügt es in wenigen Zeilen hinzu:
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
limiter = Limiter(get_remote_address, app=app, default_limits=["100 per minute"])Routenspezifische Limits können für rechenintensive Endpunkte verschärft werden. Login-Routen und Such-Endpunkte sind hierfür die üblichen Kandidaten.
Bei einem Vorfall in der Produktion entscheiden Logs darüber, ob die Diagnose fünf Minuten oder fünf Stunden dauert. Konfigurieren Sie Pythons Standard- logging -Modul für strukturierte Ausgaben und nutzen Sie die Request-Hooks von Flask (eine leichtgewichtige Form von Middleware, die Code vor und nach jeder Anfrage ausführt), um jede Log-Zeile mit einer Request-ID zu versehen:
import logging, uuid
from flask import g, request
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s [%(request_id)s] %(message)s")
@app.before_request
def assign_request_id():
g.request_id = request.headers.get("X-Request-ID", uuid.uuid4().hex)Mit Request-IDs lässt sich eine fehlerhafte Anfrage über jede erzeugte Log-Zeile hinweg nachverfolgen – und sogar über verschiedene Dienste hinweg, sofern nachgelagerte Aufrufe den Header weiterleiten. Für volle Observability sollten die Logs an einen Aggregator (CloudWatch, Grafana Loki oder eine APM-Plattform wie Sentry oder Datadog) gesendet werden, anstatt sie auf dem Server zu belassen.
Wenn ein browserbasiertes Frontend Ihre API von einer anderen Domain aus aufruft, blockiert der Browser die Anfragen, bis die API die korrekten CORS-Header (Cross-Origin Resource Sharing) sendet. Flask-CORS erledigt das:
from flask_cors import CORS
CORS(app, origins=["https://app.example.com"])Geben Sie die exakten Origins an, die Ihre Frontends verwenden. Die Verwendung von Platzhaltern für Origins mit * ist zwar eine gängige Abkürzung und ein häufiger Befund bei Sicherheitsüberprüfungen, ermöglicht aber jeder Website im Internet, Ihre API über die Browser ihrer Nutzer aufzurufen.
Aus der Audit-Praxis von IC: Von diesen fünf Punkten ist das Fehlen von Tests der entscheidende Faktor dafür, ob eine Codebasis überhaupt an ein neues Team übergeben werden kann. Eine ungetestete Flask-API ist nicht fertig. Sie läuft lediglich.
Flask ist eines der am weitesten verbreiteten Python-Web-Frameworks für die API-Entwicklung, aber es ist nicht die einzige Option. FastAPI hat sich rasant zu einem modernen Framework entwickelt, das speziell für leistungsstarke APIs konzipiert wurde.
Die Stack Overflow Developer Survey 2025 belegt diesen Wandel mit Zahlen: FastAPI und Flask werden jeweils von etwa 15 % der Befragten genutzt, wobei der Anstieg von FastAPI um fünf Prozentpunkte gegenüber dem Vorjahr zu den größten Zuwächsen unter allen Web-Frameworks zählt. Beide sind produktionsreif, verfolgen jedoch unterschiedliche Philosophien.
Ein detaillierter Blick auf die technischen Unterschiede in Bezug auf Tooling, Architektur und Entwicklererfahrung:
| Funktionskategorie | Flask | FastAPI |
|---|---|---|
| Veröffentlichungsgeschichte | Etabliert (2010) | Modern (2018) |
| Asynchrone Funktionen | Eingeschränkte Unterstützung | Natives ASGI |
| Datenintegrität | Erfordert Marshmallow | Integriert (Pydantic) |
| Selbstdokumentierend | Erfordert Erweiterungen | Automatisches OpenAPI |
| Lernaufwand | Niedrig | Mäßig (Type Hints) |
Zwei Begriffe in dieser Tabelle bedürfen einer einfachen Erklärung. ASGI (Asynchronous Server Gateway Interface) ist der Nachfolger von WSGI und ermöglicht es Python-Anwendungen, viele Anfragen gleichzeitig zu verarbeiten. Pydantic ist eine Python-Bibliothek, die Daten mithilfe von Type Hints validiert und parst; sie bildet die Grundlage für die integrierte Request-Validierung von FastAPI.
Kurz gesagt: Flask bietet einen minimalen, synchronen Kern und lässt Sie Validierung und Dokumentation über Erweiterungen wie Marshmallow und flask-smorest selbst zusammenstellen. FastAPI kehrt dieses Prinzip um: Asynchrone Verarbeitung, Validierung und OpenAPI-Dokumentation sind bereits integriert – auf Kosten eines jüngeren Ökosystems und einer gewissen Lernkurve bei der Verwendung von Type Hints.
Flask eignet sich, wenn Sie ein Framework benötigen, das sich der Anwendung anpasst und nicht umgekehrt: für kleine bis mittlere APIs, Microservices, Backend-Dienste für Webanwendungen sowie Projekte, die volle Kontrolle über die Architektur erfordern. Es ist zudem die pragmatische Wahl für Teams, die bereits mit Flask oder dessen Erweiterungs-Ökosystem vertraut sind.
Ehrlich gesagt gibt es Projekte, bei denen wir nicht zu Flask greifen würden. Wenn Ihre API ein Greenfield-Projekt ist, auf Async ausgelegt ist und Tausende gleichzeitige Verbindungen bewältigen muss (Chat, Streaming, hochfrequente Integrationen), bietet das native ASGI-Modell von FastAPI von Haus aus das, wofür Flask Workarounds benötigt. Dasselbe gilt, wenn Ihr Team mit beiden Frameworks noch nicht vertraut ist und das Projekt auf umfangreiche Request-Validierung angewiesen ist: Die integrierten Prüfungen von Pydantic nehmen Ihnen Arbeit ab, die bei Flask von Ihrer eigenen Disziplin abhängt.
FastAPI wurde speziell für APIs entwickelt und bietet von Haus aus mehr Funktionen, wie die FastAPI-Dokumentation im Detail beschreibt. Es ist die stärkere Wahl für leistungsstarke und asynchrone APIs, Codebasen, die auf Python-Typ-Hinweise setzen, sowie für Teams, die Validierung und interaktive Dokumentation automatisch generiert haben möchten, anstatt sie mühsam aus Erweiterungen zusammenzustellen.
Ehrlich gesagt ist das die falsche Frage. Flask bietet maximale Flexibilität und sechzehn Jahre ausgereiftes Ökosystem; FastAPI bietet natives Async sowie integrierte Validierung und Dokumentation. Die entscheidenden Faktoren sind die Erfahrung Ihres Teams, die Anforderungen Ihres Projekts und die Risikobewertungen, die wir im Folgenden behandeln – dieselben Faktoren, die bei jeder Entscheidung für einen Tech-Stackeine Rolle spielen.
Für CTOs und technische Leiter geht es bei der Frage Flask vs. FastAPI selten um Benchmarks. Es geht um Risiken: Einstellungsrisiken, Lieferrisiken und die langfristigen Kosten für die Wartung dessen, was Ihr Team in diesem Quartal ausliefert.
Flask ist die risikoärmere Wahl, wenn Ihr Team bereits damit vertraut ist. Entwickler mit jahrelanger Flask-Erfahrung liefern schneller und machen weniger architektonische Fehler, als dies bei einem Framework der Fall wäre, das unter Zeitdruck erlernt werden muss. Zudem bedeutet das ausgereifte Ökosystem von Flask weniger Unbekannte, sobald das System live ist. Außerdem greifen Sie auf einen der größten Pools an Fachkräften in der Python-Webentwicklung zurück (etwa jeder siebte Entwickler in der Stack Overflow-Umfrage 2025 nutzt es bereits), was wichtig ist, wenn das Team wachsen muss.
FastAPI reduziert eine andere Art von Risiko. Bei Async-lastigen APIs mit hohem Durchsatz eliminieren die integrierte Validierung und Dokumentation ganze Klassen von Fehlern, die Flask-Teams durch Disziplin und Erweiterungen selbst verhindern müssen.
Es gilt abzuwägen: Schnelle Markteinführung heute oder geringere Wartungskosten morgen? In den Codebasen, die wir prüfen, liegen die höchsten Wartungskosten selten am „falschen“ Framework. Sie entstehen dort, wo jeder Entwickler Anfragen anders validiert und niemand Tests schreibt. Diese Versäumnisse summieren sich zu technischen Schulden, unabhängig davon, für welches Framework Sie sich entschieden haben.
Was kostet das über zwölf Monate hinweg? Das Muster ist immer gleich: Die Bereitstellung von Funktionen verlangsamt sich, da jede Änderung ein erneutes Einarbeiten in undokumentiertes Verhalten erfordert, das Onboarding neuer Entwickler dauert statt Tagen plötzlich Wochen und die Diagnose des ersten schwerwiegenden Vorfalls nimmt mehr Zeit in Anspruch als nötig. Genau hier – und nicht bei der Wahl des Frameworks – macht sich eine strukturierte Architekturprüfung bezahlt.
Kurz gesagt: Flask ist ein leichtgewichtiges Python-Web-Framework, das seit 2010 kontinuierlich weiterentwickelt wird und REST-APIs durch die Zuordnung von HTTP-Routen zu Funktionen erstellt. Eine produktionsreife Flask-API ergänzt die grundlegende Tutorial-Version um fünf Aspekte: Datenbankpersistenz durch SQLAlchemy, Anforderungsvalidierung mit aussagekräftigen Fehlermeldungen, OpenAPI-Dokumentation mittels flask-smorest, eine paketbasierte Projektstruktur unter Verwendung von Blueprints sowie die Bereitstellung hinter einem produktionsreifen WSGI-Server wie Gunicorn.
FastAPI ist die wichtigste Alternative, da es bei asynchronen Arbeitslasten schneller ist und von Haus aus eine automatische Dokumentation bietet. Die Entscheidung zwischen beiden sollte auf Basis von Team-Expertise und Wartungskosten getroffen werden, nicht anhand von Benchmarks.
Wenn Sie sich nur eine Sache merken, dann diese: Nicht Frameworks verursachen Wartungskosten, sondern Gewohnheiten.
Eine Flask-API ist ein RESTful-Webservice, der mit dem Flask-Framework in Python erstellt wurde. Er stellt HTTP-Endpunkte bereit, die von Clients aufgerufen werden, wobei der Datenaustausch in der Regel im JSON-Format erfolgt.
Ja. Flask dient als Backend für APIs, die Frontend-Anwendungen, mobile Apps oder Dienste von Drittanbietern mit Daten versorgen. Erweiterungen übernehmen dabei unterstützende Aufgaben: Flask-SQLAlchemy für die Datenhaltung, Flask-JWT-Extended für die Authentifizierung und Flask-Limiter für das Rate Limiting.
Flask ist ein Web-Framework; REST ist ein Architekturstil für den Entwurf vernetzter Anwendungen. Sie verwenden Flask, um REST-APIs zu implementieren: Das Framework liefert das Routing und die Request-Verarbeitung, REST liefert die Design-Konventionen.
Ja, und zwar aus einem bestimmten Grund: Der kleine Kern sorgt dafür, dass die API nur das enthält, was Sie selbst hinzufügen. Die Kehrseite ist, dass Validierung, Dokumentation und Struktur in Ihrer Verantwortung liegen – dieser Leitfaden zeigt Ihnen, wie Sie all das umsetzen.
Ja. Etwa 15 % der Befragten im Stack Overflow Developer Survey 2025 nutzen Flask, was auf Augenhöhe mit FastAPI liegt, und das Ökosystem der Erweiterungen wird seit sechzehn Jahren kontinuierlich gepflegt. Was sich geändert hat, ist der Standard für neue, asynchron-lastige APIs, bei denen FastAPI mittlerweile die häufigere Wahl ist.
Wählen Sie Flask, wenn Ihr Team bereits damit vertraut ist, die API nicht asynchron-lastig ist oder Sie ein bestehendes Flask-System erweitern. Wählen Sie FastAPI für neue Projekte, Anwendungen mit hohem Durchsatz oder asynchrone APIs, bei denen integrierte Validierung und Dokumentation das Projektrisiko senken. Die vollständige Analyse der Vor- und Nachteile finden Sie oben im Abschnitt für Engineering-Leads.
Bei synchronen CRUD-Workloads hinter einem korrekt konfigurierten WSGI-Server ist selten das Framework der Flaschenhals, sondern meist die Datenbank. FastAPI hat bei I/O-lastigen, parallelen Workloads die Nase vorn, da sein natives ASGI-Modell viele gleichzeitige Anfragen verarbeitet, die bei Flask jeweils einen eigenen Worker belegen würden.
Sie lösen unterschiedliche Probleme. Flask ist ein Microframework, das minimalistisch beginnt und nach Bedarf wächst; Django bringt ORM, Admin-Oberfläche und Authentifizierung direkt mit. Wählen Sie Flask für APIs und Microservices, bei denen Sie volle Kontrolle wünschen; wählen Sie Django, wenn Sie eine Komplettlösung bevorzugen und bereit sind, sich an dessen Konventionen zu halten.
Ja, mit dem richtigen Server. Der integrierte Entwicklungsserver ist nicht für den Produktivbetrieb geeignet. Daher werden Deployments mit einem WSGI-Server wie Gunicorn oder uWSGI hinter einem Reverse Proxy wie Nginx betrieben, üblicherweise in Docker-Containern. So konfiguriert, bewältigt Flask produktive Workloads zuverlässig.
Mit einem WSGI-Server und einem Reverse Proxy. Die grundlegenden Schritte:
Ein typischer Gunicorn-Befehl sieht so aus:
gunicorn -w 4 "app:app"In modernen Infrastrukturen wird dieser gesamte Stack als Docker-Container auf AWS, Azure oder Google Cloud bereitgestellt.
Installieren Sie die Flask-CORS-Erweiterung und registrieren Sie diese für Ihre App mit den exakten Ursprüngen, die Ihre Frontends verwenden. Vermeiden Sie Wildcards für Ursprünge mit * in der Produktion, da es jeder Website ermöglicht, Ihre API über die Browser ihrer Besucher aufzurufen. Der Abschnitt zur Produktionsreife oben zeigt die Einrichtung in zwei Zeilen.
Der Unterschied liegt im Grad der integrierten Struktur. Flask ist ein leichtgewichtiges Microframework, bei dem Sie die Bibliotheken und die Architektur selbst wählen; Django REST Framework ist eine voll ausgestattete Ebene auf Basis von Django, die Authentifizierung, Serialisierung, Berechtigungen und API-Views bereits enthält.
Im Allgemeinen eignet sich Flask für kleine bis mittelgroße APIs, Microservices und maßgeschneiderte Architekturen, während Django REST Framework für größere Anwendungen geeignet ist, die vom integrierten Ökosystem und den Konventionen von Django profitieren.
Wenn Ihr Team entscheidet, wie eine neue API strukturiert werden soll oder ein bestehender Dienst in die Produktion überführt wird, kann Imaginary Cloud Ihre Architektur überprüfen und den richtigen Ansatz für Ihre Skalierung und Ihr Team ermitteln. Kontaktieren Sie uns , um das Gespräch zu beginnen.
.webp)
Associate Developer mit Schwerpunkt auf Backend-Technologien. Unternehmer mit einer Leidenschaft für Data Science. Begeisterter Fan von Sport, Hörbüchern, Kaffee und Memes!
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
