APIFlask starts as a fork of APIFairy (which share similar APIs with flask-smorest)
and is inspired by flask-smorest and FastAPI. So, what are the differences between
APIFlask and APIFairy/flask-smorest/FastAPI?
In a word, I try to provide an elegant (act as a framework, no need to instantiate
additional extension object) and simple (more automation support for OpenAPI/API
documentation) solution for creating web APIs with Flask. Here is a summary of the
differences between APIFlask and similar projects.
For the web part, FastAPI builds on top of Starlette, while APIFlask builts on top of
Flask.
For the data part (serialization/deserialization, OpenAPI support), FastAPI relies
on Pydantic, while APIFlask supports both Pydantic models and marshmallow.
APIFlask builds on top of Flask, so it's compatible with Flask extensions.
FastAPI supports async. APIFlask has the basic async support with Flask 2.0.
APIFlask provides more decorators to help organize things better.
FastAPI injects the input data as a Pydantic object, while APIFlask passes it as a Pydantic object (for Pydantic models) or dict (for marshmallow schemas).
APIFlask has built-in class-based views support based on Flask's MethodView.
On top of Swagger UI and Redoc, APIFlask supports more API documentation tools:
Elements, RapiDoc, and RapiPDF.
You only need to use the APIFlask class to replace the Flask class:
fromapiflaskimportAPIFlaskapp=APIFlask(__name__)
The key reasons behind making APIFlask a framework instead of a Flask
extension is it makes possible to overwrite and change the internal
behavior of Flask. For example:
Rewrite Flask.dispatch_request to ensure the natural order of the arguments
injected into the view function (APIFlask 1.x).
Add route shortcuts to the Flask and the Blueprint class (added in Flask 2.0).
Rewrite Flask.make_response to support returning list as JSON response (added in Flask 2.2).
Rewrite Flask.add_url_rule to support generating OpenAPI spec for class-based views.