Fråga fem utvecklare vad Flask är och du kommer att få fem självsäkra svar, varav de flesta är halvvägs rätt. Det här är vad det faktiskt handlar om: ett Flask-projekt i Python kan gå från en tom mapp till ett fungerande API på en eftermiddag, för att sedan, utan medvetna beslut om struktur, validering och driftsättning, i tysthet förvandlas till det system ingen vill röra. Snabbt att starta. Dyrt att försumma.
Den här guiden täcker båda sidor av den historien. Om du är utvecklare kommer vi att bygga ett fungerande REST-API tillsammans, steg för steg: CRUD-endpoints, en SQLite-databas via SQLAlchemy, validering av anrop och felhantering, OpenAPI-dokumentation samt en projektstruktur som tål att växa.
Om du är CTO eller teknisk chef och väger Python Flask mot FastAPI, hoppa direkt till avsnitten om produktionsberedskap och hur tekniska ledare bör resonera. De delarna talar ditt språk: teamets kompetens, leveransrisk och vad underhåll faktiskt kostar.
Flask är ett lättviktigt webbramverk för Python som bygger API:er och webbapplikationer genom att mappa HTTP-rutter till funktioner som returnerar JSON eller HTML. Det är ett WSGI-ramverk, och WSGI (Web Server Gateway Interface) är helt enkelt standardkopplingen mellan Python-webbapplikationer och de webbservrar som kör dem. den officiella Flask-dokumentationen kallar det för ett mikroramverk, vilket är både korrekt och något missvisande på samma gång.
Mikro beskriver kärnan, inte ambitionen. Flask ger dig ett chassi snarare än en färdig bil: motorn, sätena och instrumentpanelen är dina val, hämtade från en reservdelskatalog som communityn har fyllt på sedan 2010. Den friheten är hela tjusningen (och, som vi kommer att se, hela risken).
Python erbjuder flera ramverk: bland annat Tornado, Pyramid, Django och FastAPI. Om du fortfarande väger språket i sig, förklarar vår översikt av fördelarna med Python varför det dominerar backend- och dataarbete.
Är Flask fortfarande ett mainstream-val? Absolut. I 2025 Stack Overflow Developer Surveyuppgav ungefär 15 % av respondenterna att de använder Flask, vilket placerar det, tillsammans med FastAPI, bland de mest använda webbramverken oavsett språk. Reservdelskatalogen är lika mogen: Flask-SQLAlchemy för databaser, Flask-Login och Flask-JWT-Extended för autentisering, Flask-Migrate för schema-migreringar, Flask-Limiter för hastighetsbegränsning. Var och en underhållen i åratal.
Från IC:s granskningsverksamhet: Flasks frihet är ett tveeggat svärd. Det gör de första veckorna i ett Flask-Python-projekt snabba, och det är också den vanligaste anledningen till att vi blir ombedda att reda ut en kodbas ett år senare. Ramverket hindrar inte tre utvecklare från att hitta på tre olika strukturer i samma applikation. Ingenting gör det, förutom teamet.
API står för Application Programming Interface: hur ett system kommunicerar med ett annat. Ett REST-API (Representational State Transfer) är en arkitekturstil för denna kommunikation, byggd på tillståndslösa anrop via standardiserade HTTP-metoder, där klientens och serverns ansvarsområden hålls strikt åtskilda.
I praktiken utbyter ett REST-API JSON-data och mappar slutpunkter till fyra verb: Skapa (POST), Läsa (GET), Uppdatera (PUT eller PATCH) och Ta bort (DELETE). Tillsammans kallas dessa för CRUD-operationer, och det API du kommer att bygga i den här guiden implementerar alla fyra för en enskild entitet. REST är dock inte den enda stilen. Om dina tjänster är interna och latenskänsliga, förklarar vår jämförelse mellan gRPC och REST när ett binärt protokoll är att föredra.
Från IC:s granskningsverksamhet: det vanligaste designproblemet vi ser i REST-API:er är inte en saknad slutpunkt. Det är inkonsekvens: en rutt returnerar snake_case, en annan camelCase; en paketerar felmeddelanden i JSON, en annan skickar en ren HTML-sida. Att komma överens om dessa konventioner innan den första slutpunkten skapas tar en timme men sparar veckor av arbete.
Varje Flask-API kräver samma grundarbete innan en enda rad applikationskod skrivs. Låt oss lägga den grunden.
Du måste ha Python installerat. Koden här förutsätter Python 3; om du använder Windows eller behöver Python 2, följ installationsguiden för Flask.
Börja med att skapa en katalog för projektet. Kör följande kommandon i terminalen på den plats där du vill att projektet ska ligga:
mkdir flask_api
cd flask_api
Vi har skapat projektkatalogen och navigerat in i den. Innan du installerar något, skapa en virtuell miljö:
python3 -m venv venv
Detta skapar en mapp med namnet venv i ditt projekt. Aktivera den genom att köra:
source venv/bin/activate
# On Windows:
venv\Scripts\activate
Från och med nu använder all Python-kod du kör venv-miljön. Om du arbetar i en IDE, peka den mot samma miljö (en klassisk källa till förvirring av typen "det fungerar i terminalen").
Hur vet du att den är aktiv? Titta till vänster i konsolen: om miljöns namn står inom parentes är allt klart. För att avaktivera den senare, kör:
deactivate
Ett typiskt Python Flask-API byggs i sex steg:
Den här guiden följer den ordningen eftersom vi gör detsamma i våra kundprojekt. Det håller backend-tjänster organiserade från första commiten, inte från den femtonde refaktoriseringen.
.webp)
Ett API som lagrar data i en Python-lista glömmer allt så fort servern startas om. Riktiga applikationer sparar data permanent, så i det här avsnittet ansluter vi Flask-API:et till en databas med hjälp av SQLite och SQLAlchemy.
SQLite är en lättviktsdatabas som inte kräver någon separat server, vilket gör den idealisk för guider och mindre applikationer. Perfekt för idag. Inte nödvändigtvis för lanseringsdagen.
Från IC:s granskningsverksamhet: nästan alla Flask-projekt vi tar över började med SQLite "bara för stunden". Det är en bra startpunkt, förutsatt att SQLAlchemy-modellerna skrivs som om PostgreSQL vore på väg. För i produktion är det oftast precis vad som väntar.
Installera de nödvändiga beroendena:
pip install Flask Flask-SQLAlchemy
Om du hanterar beroenden med en requirements.txt -fil, lägg till:
Flask
Flask-SQLAlchemy
I den här konfigurationen är SQLAlchemy din Object Relational Mapper. En ORM (Object Relational Mapper) låter dig hantera databasposter som vanliga Python-objekt istället för att skriva rå SQL; SQLAlchemy-dokumentationen täcker hela dess utbud. Flask-SQLAlchemy kopplar ihop det med Flask.
Peka Flask mot SQLite-databasen genom att definiera anslutningssträngen:
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)
Detta skapar en lokal SQLite-databasfil med namnet items.db i projektkatalogen.
Skapa en modell som representerar strukturen för databastabellen:
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}
Modellen Item definierar tre fält: id (unik identifierare), name och pris. to_dict() -metoden konverterar databasobjektet till en JSON-serialiserbar dictionary.
Innan du kör API:et, skapa tabellerna med SQLAlchemy:
with app.app_context():
db.create_all()
Denna endpoint returnerar varje objekt som lagras i databasen:
@app.route("/items", methods=["GET"])
def get_items():
items = Item.query.all()
return jsonify([item.to_dict() for item in items])
Denna endpoint läser JSON-förfrågningskroppen, validerar indata, skapar en databaspost och returnerar det skapade objektet:
@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
Denna endpoint hämtar ett specifikt objekt via dess ID:
@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())Om objektet inte finns returnerar Flask automatiskt ett 404-fel. Ingen extra kod krävs.
Denna slutpunkt uppdaterar ett befintligt objekt. Endast de angivna fälten ändras.
@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())
Denna slutpunkt tar bort det angivna objektet från databasen:
@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."})
Starta Flask-utvecklingsservern:
python app.py
# or, with the Flask CLI:
flask --app app run --debugDitt API är nu tillgängligt lokalt.
Skapa ett nytt objekt, anropet:
curl -X POST http://localhost:5000/items \
-H "Content-Type: application/json" \
-d '{"name": "Keyboard", "price": 49.9}'
Svaret:
{
"id": 1,
"name": "Keyboard",
"price": 49.9
}
Hämta alla objekt, svaret:
[
{
"id": 1,
"name": "Keyboard",
"price": 49.9
}
]
Eftersom listor förlorar data vid omstart, inte kan delas mellan applikationsinstanser och inte kan sökas effektivt. En databas som SQLite ger ditt API persistent, sökbar lagring: det beteende som en riktig backend-tjänst kräver.
För produktionssystem går team vanligtvis över till PostgreSQL, MySQL eller MongoDB. Den övergripande strukturen för Flask-API:et förblir densamma.
Se ett API i en enda fil som en etta. Allt finns inom räckhåll, ingen planlösning behövs, och för ett litet projekt är det precis poängen:
flask_api/
├── app.py
├── models.py
├── routes.py
├── requirements.txt
└── items.dbI den här strukturen app.py skapar Flask-applikationen och konfigurerar tillägg, models.py definierar SQLAlchemy-modellerna, routes.py innehåller slutpunkterna, requirements.txt listar beroenden, och items.db är utvecklingsdatabasen.
Den här layouten passar små API:er, prototyper och utbildningsprojekt. Men ingen bildar familj i en etta, och ingen bör låta en produkt växa i en enda fil.
app.py skapar Flask-applikationen, konfigurerar databasen och registrerar rutterna.
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 definierar databasmodellen.
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 innehåller API-slutpunkterna.
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.routeGenom att dela upp applikationen i flera filer hålls ansvarsområdena tydliga och röran nere. Om du senare lägger till autentisering, användare eller beställningar utökar du strukturen istället för att skriva om projektet.
Större Python Flask-applikationer behöver ett hus, inte en lägenhet: paket istället för filer på toppnivå, med ett märkt rum för varje ansvarsområde.
flask_api/
├── app/
│ ├── __init__.py
│ ├── models/
│ │ └── item.py
│ ├── routes/
│ │ └── items.py
│ └── schemas/
│ └── item.py
├── requirements.txt
└── run.pyI denna arkitektur innehåller app-paketet huvudapplikationens logik, models/ definierar databasmodeller, routes/ grupperar slutpunkter efter resurs, och run.py startar applikationen. Mappen schemas/ hanterar validering av förfrågningar och svar med hjälp av Marshmallow, ett Python-bibliotek för att definiera scheman som validerar inkommande data och serialiserar utgående svar.
Fördelarna är tydliga. Slutpunkter förblir organiserade efter resurs, funktioner som autentisering eller bakgrundsjobb kan enkelt läggas till, och flera utvecklare kan arbeta parallellt utan att komma i vägen för varandra.
Bästa praxis: börja med den enkla strukturen och expandera först när applikationen växer. För små projekt räcker det med några få tydligt namngivna filer. För större Flask-API:er är den paketbaserade layouten det som håller underhållskostnaderna nere.
En blueprint är ett objekt som liknar ett Flask-applikationsobjekt, med skillnaden att den utökar den befintliga applikationen istället för att skapa en ny. Blueprints är verktyget du använder för att dela upp ett Flask-API i sektioner: efter resurs, API-version eller tjänst.
Så när behöver du dem egentligen? Tidigare än du tror.
Från IC:s granskningspraxis: en enskild fil för rutter börjar dra på sig merge-konflikter så fort en andra utvecklare ansluter eller en andra resurs dyker upp. Det är signalen för att gå över till Blueprints. Inte först när filen till slut "känns" för lång.
Låt oss konvertera koden ovan till en blueprint och läsa in den i huvudapplikationen. Skapa en ny mapp med namnet blueprints, och inuti den en mapp och en fil för items-blueprinten:
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
Nu behöver app.py bara läsa in den skapade blueprinten och registrera den på applikationsobjektet:
from blueprints.items.routes import items_bp
app.register_blueprint(items_bp)Samma slutpunkter, bättre struktur. Det är detta som gör att en växande Flask-applikation i Python förblir hanterbar.
Validering är dörrvakten för ditt API. Den kontrollerar behörigheten vid ingången så att du slipper dra in dålig data i databasen, där den annars hinner ställa till med problem i dina rapporter. Ett välutformat Flask-API validerar inkommande data, returnerar tydliga felmeddelanden och använder korrekta HTTP-statuskoder.
Från IC:s granskningspraxis: i de produktionsincidenter vi kallas in för att diagnostisera är bristande validering av förfrågningar en av de vanligaste grundorsakerna. Dålig data smyger sig in obemärkt och dyker sedan upp veckor senare som ett rapporteringsfel som är kostsamt att spåra tillbaka till källan.
När en klient skickar data bör servern verifiera att obligatoriska fält finns med och är korrekt formaterade. Att skapa ett nytt objekt bör till exempel kräva både ett namn och ett pris.
Här är ett enkelt valideringsexempel:
@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()), 201API:et kontrollerar att förfrågningskroppen innehåller JSON och att de obligatoriska fälten finns med. Om valideringen misslyckas returneras ett 400 Bad Request -svar. Dörrvakten säger nej vid dörren, artigt och i JSON-format.
Statuskoder talar om för klienter om en förfrågan lyckades eller misslyckades. De vanligaste i REST-API:er är:
Rätt kod gör att API-användare kan hantera svar programmatiskt istället för att tolka felmeddelanden i textform.
När en klient efterfrågar en resurs som inte finns bör API:et returnera ett 404-fel. Flask-SQLAlchemy tillhandahåller en smidig hjälpare:
@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())
Om objektet inte finns returnerar Flask automatiskt ett svar som:
{
"error": "Resource not found"
}Inga tomma svar, inga vilseledande svar.
I större applikationer bör du definiera globala felhanterare som returnerar konsekventa svar för vanliga fel:
@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"}), 500Med dessa hanterare returnerar API:et alltid strukturerad JSON istället för standardiserade HTML-felsidor.
Om en klient försöker skapa ett objekt utan de obligatoriska fälten kan API:et returnera:
{
"error": "Both 'name' and 'price' are required."
}Tydliga felmeddelanden gör att utvecklare som integrerar mot ditt API kan diagnostisera sina egna misstag utan att behöva läsa din källkod. Ditt framtida jag räknas för övrigt också som en sådan utvecklare.
Tillsammans håller de ogiltig data borta från databasen, gör svaren förutsägbara och låter integrerare felsöka snabbt. Det är standardpraxis inom modern API-utveckling och ett absolut krav för en Flask-tjänst i produktion.
Moderna API:er bör tillhandahålla maskinläsbar dokumentation så att utvecklare kan förstå slutpunkter, begärandeformat och svar utan att behöva läsa koden. Den dominerande standarden är OpenAPI, som beskriver HTTP-API:er i ett format som verktyg kan tolka automatiskt.
I Flask är den smidigaste vägen flask-smorest, ett bibliotek som kopplar samman Flask med OpenAPI 3, validering av anrop och automatisk Swagger UI-dokumentation.
Installera de nödvändiga paketen:
pip install flask-smorest marshmallowEller lägg till dem i din requirements.txt -fil:
flask-smorest
marshmallowI den här konfigurationen flask-smorest genererar OpenAPI-dokumentationen och hanterar API-routing, medan marshmallow (som introducerades i strukturavsnittet) sköter validering av anrop och serialisering av svar.
Innan du skapar slutpunkter, konfigurera applikationen för att generera dokumentation:
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"Viktiga inställningar inkluderar API_TITLE (namnet på ditt API), API_VERSION, OPENAPI_VERSION (specifikationsversionen) och OPENAPI_SWAGGER_UI_PATH (var den interaktiva dokumentationen finns, till exempel /swagger-ui).
Med flask-smorest definieras formen på den data ditt API accepterar och returnerar med Marshmallow-scheman. Skapa ett som beskriver ett objekt:
from marshmallow import Schema, fields
class ItemSchema(Schema):
id = fields.Int(dump_only=True)
name = fields.Str(required=True)
price = fields.Float(required=True)Ett schema gör fyra saker: det validerar inkommande förfrågningar, dokumenterar det förväntade formatet, serialiserar svar och genererar korrekt OpenAPI-utdata. Det är därför vi rekommenderar att man börjar med scheman.
Skapa slutpunkter med en Blueprint, och grupperar relaterade rutter:
from flask_smorest import Blueprint
blp = Blueprint("items", __name__, url_prefix="/items", description="Operations on items")Varje blueprint blir ett avsnitt i den genererade dokumentationen.
Implementera nu slutpunkter för att skapa och hämta objekt:
@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 itemHär @blp.arguments validerar den inkommande förfrågningskroppen, @blp.response dokumenterar och serialiserar utdata, och MethodView grupperar flera HTTP-metoder under en och samma rutt. Dekoratorerna uppdaterar OpenAPI-dokumentationen automatiskt.
Registrera din blueprint hos API-instansen för att aktivera slutpunkterna:
api.register_blueprint(blp)
När applikationen körs, öppna Swagger UI-URL:en i din webbläsare:
http://localhost:5000/swagger-uiDet interaktiva Swagger UI-gränssnittet låter dig se alla slutpunkter, inspektera parametrar, testa anrop direkt från webbläsaren och utforska scheman. Eftersom OpenAPI är en branschstandard driver dessutom samma specifikation generering av klienter och automatiserade verktyg för API-testning.
Klarar Flasks inbyggda server av produktion? Nej. Den är till för utveckling, och produktionsmiljöer kräver en WSGI-server och en webbserver för att hantera verklig trafik på ett tillförlitligt sätt.
Från IC:s granskningsverksamhet: ett återkommande problem i våra granskningar är att Flasks utvecklingsserver används i produktion för att det "fungerade". Det gör det. Tills samtidig trafik uppstår.
En vanlig driftsättningskonfiguration kombinerar Gunicorn eller uWSGI som WSGI-server med Nginx som reverse proxy, hostad på en moln- eller containerplattform som AWS, Azure eller Google Cloud. Gunicorn och uWSGI är WSGI-servrar av produktionsklass: program som kör flera kopior av din Python-applikation och hanterar inkommande förfrågningar, vilket är precis den uppgift som den entrådiga utvecklingsservern aldrig var designad för.
Kör till exempel en Flask-applikation i produktion med Gunicorn:
gunicorn -w 4 "app:app"I detta kommando -w 4 startar fyra arbetsprocesser och app:app refererar till Flask-applikationsobjektet.
I moderna miljöer levereras Flask-API:er vanligtvis som Docker-containrar, vilket förenklar skalning, miljöhantering och kontinuerlig driftsättning. Om ditt team använder Kubernetes, täcker vår guide om att bygga en Kubernetes-optimerad CI/CD-pipeline hur containeriserade API:er som detta går från commit till kluster.
De flesta API:er i produktionsmiljö begränsar åtkomsten så att endast behöriga användare eller tjänster kan nå skyddade slutpunkter. De vanligaste metoderna är API-nycklar för enkel tjänst-till-tjänst-åtkomst, JWT (JSON Web Tokens) för användarautentisering, och OAuth 2.0 för tredjepartsintegrationer.
JWT-baserad autentisering är det mönster vi oftast använder för Flask-API:er. En användare loggar in med sina uppgifter, servern utfärdar en signerad token, och klienten skickar med denna token i varje anrop via headern Authorization (headernamnet behåller sin amerikanska stavning eftersom HTTP-standarden definierar det så).
Exempel på header:
Authorization: Bearer <your-jwt-token>
Tillägg som Flask-JWT-Extended hanterar token-hantering och skydd av rutter så att du slipper implementera kryptografi från grunden. Med autentisering på plats når endast behöriga klienter API:et, känslig data förblir skyddad och användningen kan övervakas per klient.
Från IC:s granskningspraxis: vi ser autentisering som en del av den grundläggande arkitekturen, inte som en säkerhetsåtgärd i slutskedet. Att efterhand implementera det över dussintals befintliga slutpunkter är konsekvent dyrare än att designa in det från den första rutten.
Handledningar slutar oftast vid att "API:et fungerar". Innan vi på Imaginary Cloud godkänner ett Flask-API för produktion måste det klara vår checklista för produktionsberedskap – samma granskning som vi tillämpar i våra Tekniska och UX-revisioner.
Fem punkter på den checklistan saknas i de flesta Flask-guider:
Låt oss gå igenom dem en efter en.
Flask levereras med en testklient som anropar dina slutpunkter utan att köra en server, och den fungerar utmärkt tillsammans med pytest. Ett minimalt test ser ut så här:
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"Enhetstester täcker enskilda funktioner; integrationstester som det ovan testar hela anropscykeln, från routing via validering och databas till serialisering. Kör båda i CI vid varje commit, mot en tillfällig databas.
Databas-URL:er, JWT-signeringsnycklar och inloggningsuppgifter till tredjepartstjänster får aldrig hårdkodas eller checkas in i versionshanteringen. Läs dem från miljövariabler istället. Lokalt gör en .env -fil som laddas med python-dotenv detta smidigt:
import os
from dotenv import load_dotenv
load_dotenv()
SQLALCHEMY_DATABASE_URI = os.environ["DATABASE_URL"]
JWT_SECRET_KEY = os.environ["JWT_SECRET_KEY"]Lägg till .env i .gitignore. I produktionsmiljö injicerar du samma variabler via plattformens hanterare för hemligheter (AWS Secrets Manager, Azure Key Vault eller Kubernetes-hemligheter).
Hastighetsbegränsning skyddar API:et från missbruk och från välmenande klienter som fastnat i återförsöksloopar. Flask-Limiter lägger till det på några rader:
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"])Hastighetsbegränsningar per rutt kan sedan skärpas för resurskrävande slutpunkter. Inloggningsvägar och sökfunktioner är de vanligaste kandidaterna.
När en incident inträffar i produktion är loggar skillnaden mellan en diagnos på fem minuter och en på fem timmar. Konfigurera Pythons standardmodul logging med strukturerad utdata och använd Flasks request hooks (en lättviktsform av middleware som kör kod före och efter varje anrop) för att tagga varje loggrad med ett request-ID:
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)Med request-ID:n på plats kan ett misslyckat anrop spåras genom varje loggrad det genererat, och även över flera tjänster om nedströmsanrop skickar vidare headern. För fullständig observerbarhet bör loggarna skickas till en aggregator (CloudWatch, Grafana Loki eller en APM-plattform som Sentry eller Datadog) istället för att lämnas kvar på servern.
Om en webbläsarbaserad frontend anropar ditt API från en annan domän blockerar webbläsaren anropen tills API:et skickar rätt CORS-headers (Cross-Origin Resource Sharing). Flask-CORS hanterar detta:
from flask_cors import CORS
CORS(app, origins=["https://app.example.com"])Lista de exakta ursprung som dina frontends använder. Att använda jokertecken för ursprung med * är en vanlig genväg, och en vanlig upptäckt vid säkerhetsgranskningar, eftersom det tillåter vilken webbplats som helst på internet att anropa ditt API från användarnas webbläsare.
Från IC:s granskningspraxis: av dessa fem är avsaknad av tester den faktor som avgör om en kodbas överhuvudtaget kan överlämnas till ett nytt team. Ett Flask-API utan tester är inte färdigt. Det råkar bara fungera för tillfället.
Flask är ett av de mest använda ramverken för webbutveckling i Python för att bygga API:er, men det är inte det enda alternativet. FastAPI har vuxit snabbt som ett modernt ramverk särskilt utformat för högpresterande API:er.
Stack Overflow Developer Survey 2025 sätter siffror på den förskjutningen: FastAPI och Flask används vardera av ungefär 15 % av respondenterna, och FastAPIs ökning med fem procentenheter jämfört med föregående år var en av de största för något webbramverk. Båda är redo för produktion. De har bara olika filosofier.
En detaljerad genomgång av de tekniska skillnaderna, inklusive verktyg, arkitektur och utvecklarupplevelse:
Två termer i den här tabellen förtjänar en enkel förklaring. ASGI (Asynchronous Server Gateway Interface) är efterföljaren till WSGI som gör att Python-applikationer kan hantera många förfrågningar samtidigt. Pydantic är ett Python-bibliotek som validerar och tolkar data med hjälp av typ-tips (type hints), och det driver FastAPIs inbyggda validering av förfrågningar.
Kort sagt: Flask ger dig en minimal, synkron kärna och låter dig sätta ihop validering och dokumentation med hjälp av tillägg som Marshmallow och flask-smorest. FastAPI vänder på det förhållandet. Asynkron hantering, validering och OpenAPI-dokumentation ingår från start, på bekostnad av ett nyare ekosystem och en inlärningskurva för typ-tips.
Flask passar när du behöver ett ramverk som anpassar sig efter applikationen snarare än tvärtom: små och medelstora API:er, mikrotjänster, backend-tjänster för webbapplikationer och projekt som kräver full kontroll över arkitekturen. Det är också det pragmatiska valet för team som redan är bekväma med Flask eller dess ekosystem av tillägg.
Sanningen är att det finns projekt där vi inte skulle välja Flask. Om ditt API är ett nytt projekt, är async-first och förväntas hantera tusentals samtidiga anslutningar (chatt, streaming, högfrekventa integrationer), gör FastAPIs inbyggda ASGI-modell direkt det som Flask kräver lösningar för. Detsamma gäller om ditt team är nytt för båda ramverken och projektet kräver omfattande validering av anrop: Pydantics inbyggda kontroller eliminerar arbete som Flask annars kräver att du sköter manuellt.
FastAPI är byggt specifikt för API:er och levereras med mer funktionalitet direkt från start, vilket FastAPI-dokumentationen beskriver i detalj. Det är det starkare valet för högpresterande och asynkrona API:er, kodbaser som förlitar sig på Pythons typ-hints, samt team som vill ha validering och interaktiv dokumentation genererad automatiskt istället för att behöva bygga ihop den med tillägg.
Det är ärligt talat fel fråga. Flask erbjuder maximal flexibilitet och sexton års mognad i ekosystemet; FastAPI erbjuder inbyggt stöd för async samt inbyggd validering och dokumentation. De avgörande faktorerna är ditt teams erfarenhet, projektets krav och de riskavvägningar som vi går igenom härnäst – samma faktorer som styr alla beslut om teknikstack.
För CTO:er och teknikledare handlar frågan om Flask kontra FastAPI sällan om prestandatester. Det handlar om risk: rekryteringsrisk, leveransrisk och den långsiktiga kostnaden för att underhålla det som teamet levererar under kvartalet.
Flask är det alternativ med lägst risk när teamet redan behärskar det. Utvecklare med mångårig erfarenhet av Flask levererar snabbare och gör färre arkitektoniska misstag än de skulle göra i ett ramverk som de tvingas lära sig under tidspress, och Flasks mogna ekosystem innebär färre okända faktorer när systemet väl är i drift. Dessutom drar det nytta av en av de största rekryteringspoolerna inom Python-webbutveckling (ungefär var sjunde utvecklare i 2025 års Stack Overflow-undersökning använder det redan), vilket är viktigt när teamet behöver växa.
FastAPI minskar en annan typ av risk. För asynkrona API:er med hög genomströmning eliminerar dess inbyggda validering och dokumentation hela kategorier av fel som Flask-team annars måste förebygga genom disciplin och tillägg.
Avvägningen handlar om tid till marknad nu kontra underhållskostnader senare. I de kodbaser vi granskar är de system som är dyrast att underhålla sällan byggda på "fel" ramverk: det är de system där varje utvecklare validerat förfrågningar på olika sätt och ingen har skrivit tester. Dessa brister ackumuleras som teknisk skuld oavsett vilket ramverk du har valt.
Vad kostar det under tolv månader? Mönstret är konsekvent: leveranstakten saktar ner eftersom varje ändring kräver att man på nytt lär sig odokumenterat beteende, introduktionen av en ny utvecklare sträcker sig från dagar till veckor, och den första allvarliga incidenten tar längre tid att diagnostisera än vad den borde. Det är där, snarare än i valet av ramverk, som en strukturerad arkitekturgranskning betalar sig.
Kortfattat: Flask är ett lättviktigt webbramverk för Python som varit under ständig utveckling sedan 2010 och som bygger REST-API:er genom att mappa HTTP-rutter till funktioner. Ett produktionsklart Flask-API lägger till fem saker utöver grundversionen från guider: databashantering via SQLAlchemy, validering av anrop med tydliga felmeddelanden, OpenAPI-dokumentation genererad med flask-smorest, en paketbaserad projektstruktur med Blueprints samt driftsättning bakom en produktions-WSGI-server som Gunicorn.
FastAPI är det främsta alternativet, som är snabbare för asynkrona arbetslaster och har inbyggd dokumentation. Valet mellan dem bör baseras på teamets kompetens och underhållskostnader, inte på prestandatester.
Om du bara minns en sak, låt det vara denna: ramverk skapar inte underhållskostnader. Det gör dina vanor.
Ett Flask-API är en RESTful-webbtjänst byggd med ramverket Flask i Python. Det exponerar HTTP-slutpunkter som klienter anropar, där data vanligtvis utbyts i JSON-format.
Ja. Flask fungerar som backend för API:er som förser frontend-applikationer, mobilappar eller tredjepartstjänster med data. Tillägg hanterar stödjande funktioner: Flask-SQLAlchemy för data, Flask-JWT-Extended för autentisering och Flask-Limiter för hastighetsbegränsning.
Flask är ett webbramverk; REST är en arkitekturstil för att designa nätverksbaserade applikationer. Du använder Flask för att implementera REST-API:er: ramverket tillhandahåller routing och hantering av anrop, medan REST tillhandahåller designkonventionerna.
Ja, av en specifik anledning: dess lilla kärna innebär att API:et bara innehåller det du själv lägger till. Baksidan är att validering, dokumentation och struktur är ditt ansvar, och den här guiden täcker hur du lägger till var och en av dessa delar.
Ja. Cirka 15 % av respondenterna i 2025 års Stack Overflow Developer Survey använder Flask, vilket är i nivå med FastAPI, och dess ekosystem av tillägg har underhållits kontinuerligt i sexton år. Det som har förändrats är standardvalet för nya asynkrona API:er, där FastAPI numera är det vanligare valet.
Välj Flask om ditt team redan behärskar det, om API:et inte är asynkront tungt eller om du bygger vidare på ett befintligt Flask-system. Välj FastAPI för nya projekt, hög genomströmning eller asynkrona API:er där inbyggd validering och dokumentation minskar risken vid leverans. Den fullständiga analysen av för- och nackdelar finns i avsnittet för tekniska ledare ovan.
För synkrona CRUD-arbetslaster bakom en korrekt konfigurerad WSGI-server är det sällan ramverket som utgör flaskhalsen. Det är oftast databasen. FastAPI drar ifrån ordentligt vid I/O-intensiva, samtidiga arbetslaster, där dess inbyggda ASGI-modell hanterar många samtidiga förfrågningar som annars skulle uppta varsin Flask-worker.
De löser olika problem. Flask är ett mikroramverk som börjar minimalistiskt och växer efter behov; Django levereras med inbyggd ORM, administrationsgränssnitt och autentisering. Välj Flask för API:er och mikrotjänster där du vill ha kontroll; välj Django när du vill ha en komplett lösning och accepterar dess konventioner.
Ja, med rätt server. Den inbyggda utvecklingsservern är inte säker för produktion, så driftsättningar kör en WSGI-server som Gunicorn eller uWSGI bakom en omvänd proxy som Nginx, vanligtvis inuti Docker-containrar. Konfigurerat på det sättet hanterar Flask produktionsarbetslaster på ett tillförlitligt sätt.
Med en WSGI-server och en omvänd proxy. De grundläggande stegen är:
Ett vanligt Gunicorn-kommando ser ut så här:
gunicorn -w 4 "app:app"I modern infrastruktur levereras hela stacken som en Docker-container på AWS, Azure eller Google Cloud.
Installera tillägget Flask-CORS och registrera det i din app med de exakta ursprung som dina frontend-applikationer använder. Undvik att använda jokertecken för ursprung med * i produktion, eftersom det tillåter vilken webbplats som helst att anropa ditt API från besökarnas webbläsare. Avsnittet om produktionsberedskap ovan visar konfigurationen på två rader.
Skillnaden ligger i nivån av inbyggd struktur. Flask är ett lättviktigt mikroramverk där du själv väljer bibliotek och arkitektur; Django REST Framework är ett fullfjädrat lager ovanpå Django som inkluderar autentisering, serialisering, behörigheter och API-vyer.
Generellt sett passar Flask för små till medelstora API:er, mikrotjänster och anpassade arkitekturer, medan Django REST Framework passar större applikationer som drar nytta av Djangos integrerade ekosystem och konventioner.
Om ditt team ska bestämma hur ett nytt API ska struktureras eller om ni planerar att flytta en befintlig tjänst till produktion, kan Imaginary Cloud granska er arkitektur och identifiera rätt tillvägagångssätt för er skala och ert team. Kontakta oss för att inleda samtalet.
.webp)
Associerad utvecklare som arbetar mest med Backend-teknik. En entreprenör med datavetenskapligt intresse. Kärlek till sport, ljudböcker, kaffe och memes!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
People who read this post, also found these interesting:
.webp)
