RESTful web services in Python come in three flavors: Flask (minimal, plug-everything-yourself), FastAPI (typed, async-first, OpenAPI by default), and Django REST Framework (batteries-included, ORM-integrated, opinionated). The right choice depends on three questions: does the team want async I/O, does the team want the OpenAPI doc auto-generated, and does the team already have a Django project. The mistake every team makes is picking a framework based on team familiarity instead of data shape — and then spending six months fighting the framework.
Table of contents
- Flask — the minimal canvas
- FastAPI — typed, async, OpenAPI by default
- Django REST Framework — batteries-included, ORM-integrated
- The async question — FastAPI for websockets and SSE, Flask for the rest
- The JSON contract mistake — the team that breaks the client on every deploy
- The right framework for the team’s actual project
- How this fits the rest of the stack
- FAQ
Flask — the minimal canvas
Flask is the minimal canvas. A Flask app is a single file, the routing is explicit, the request/response cycle is plain Python, and the team picks the ORM, the auth, the validation, the serialization, the test client. The right answer is Flask for a small service (5-20 routes, no async I/O, no complex auth), for a team that wants full control over the dependencies, and for a microservice that does one thing well.
The gotcha: Flask is a canvas, not a framework. The team that picks Flask and then needs auth, validation, OpenAPI, pagination, and serialization builds all of it themselves. The right answer is to add flask-smorest (for OpenAPI + marshmallow) or to switch to FastAPI if the OpenAPI auto-generation is the main reason the team was going to build it.
FastAPI — typed, async, OpenAPI by default
FastAPI is the typed, async-first, OpenAPI-default answer. The team’s route is a function with type hints, the framework validates the input, generates the OpenAPI spec, runs the handler in an async event loop, and returns the typed response. The right answer is FastAPI for a new service, for a team that wants the OpenAPI doc to be a first-class artifact, for a team that needs async I/O (websockets, SSE, long-polling), and for a team that values type safety end to end.
The gotcha: FastAPI’s dependency on Pydantic is a feature, not a bug, but the team that is not familiar with Pydantic has a learning curve. The right answer is to start with one FastAPI endpoint, learn the Pydantic models, then expand. The wrong answer is to skip Pydantic and use raw dicts — the type safety is the main benefit, and the team loses it.
Django REST Framework — batteries-included, ORM-integrated
Django REST Framework is the batteries-included, ORM-integrated answer. The team’s serializer is a class, the viewset is a class, the router wires the URL, the permissions are a class, the throttle is a class. The right answer is DRF for a team that already has a Django project, for a service that needs the admin panel, for a team that wants the ORM (with its migrations) to be the source of truth, and for a team that values convention over configuration.
The gotcha: DRF is heavy. The team’s microservice that does one thing well does not need DRF’s full machinery. The right answer is DRF for the team’s main API surface, FastAPI or Flask for the team’s edge services. The wrong answer is to use DRF for a 10-route service — the framework’s overhead is more than the code it saves.
The async question — FastAPI for websockets and SSE, Flask for the rest
Flask is synchronous by default. The team that needs websockets, Server-Sent Events, or long-polling either uses Flask-SocketIO (which adds an eventlet/gevent dependency) or switches to FastAPI. FastAPI is async-first — the team writes async def handlers, the framework runs them on the asyncio event loop, websockets and SSE are first-class.
The right answer is FastAPI for the team that has real-time features. The right answer is Flask for the team that has a CRUD service with no real-time requirement — Flask’s sync request handler is fine for thousands of requests per second, and the team’s mental model is simpler.
The JSON contract mistake — the team that breaks the client on every deploy
The mistake every team makes: the team deploys a new version of the API, a field’s type changes from string to integer, the client breaks in production, the team spends a day debugging. The right answer is a typed contract that the team validates on every deploy: Pydantic in FastAPI, marshmallow in Flask, the serializer in DRF. The wrong answer is request.json with no validation — the team’s dict accepts anything, the production client gets nothing back.
The right answer for a team that ships a JSON API is to use a framework that generates the typed client from the server’s contract. FastAPI generates a TypeScript client via openapi-typescript-codegen or openapi-generator. DRF generates one via drf-spectacular + the same tools.
The right framework for the team’s actual project
The right answer is a function of the team’s context:
- New service, no Django, async I/O, OpenAPI by default — FastAPI.
- New service, no Django, no async, small surface — Flask + flask-smorest.
- Existing Django project, ORM as source of truth, admin panel — Django REST Framework.
- Edge service, single responsibility, no auth — Flask, no extension.
- Real-time features (websockets, SSE) — FastAPI.
- Microservice with 5-10 routes, no complex auth — Flask.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is the best Python framework for REST APIs?
FastAPI for a new service with OpenAPI and async, Django REST Framework for a team that already has Django, Flask for a small service with no async requirement.
Is Flask still relevant in 2026?
Yes. Flask is the right answer for a small service, a microservice, a team that wants full control over dependencies.
Is FastAPI better than Flask?
For a new service, yes — FastAPI gives async, type safety, and OpenAPI by default. For a small service, Flask is simpler.
What is the difference between Django REST Framework and FastAPI?
DRF is batteries-included, ORM-integrated, opinionated. FastAPI is async-first, OpenAPI-by-default, lighter weight.
How do I add OpenAPI to a Flask project?
Use flask-smorest for OpenAPI + marshmallow validation, or flask-restx for the older Swagger spec.
How do I generate a TypeScript client from a Python API?
Use openapi-typescript-codegen or openapi-generator-cli against the OpenAPI spec. FastAPI serves the spec at /openapi.json.
Which Python framework is fastest?
FastAPI on uvicorn with async handlers is the fastest for I/O-bound workloads. Flask on gunicorn with sync workers is the fastest for CPU-bound workloads.
How do I deploy a Python REST API?
The right answer is a managed platform with a Python runtime, a managed Postgres, and a managed deploy pipeline. The team should not be configuring nginx + gunicorn + systemd in 2026.