Why
Every FastAPI project ends up with the same folder layout, the same CRUD
routes, the same Pydantic models copied and renamed. fullapi generates that
from one api.yaml file instead. The part that actually matters is check:
it fails CI the moment the running app stops matching the spec, so the spec
stays true instead of turning into documentation nobody trusts.
Install
pip install fullapi
Needs Python 3.9 or newer.
Setup
Start with a spec file. Either write api.yaml by hand or run:
fullapi init
which drops a starter file you can edit. A minimal spec looks like this:
name: shop_api
database: sqlite # none | sqlite | postgres
auth: jwt # optional
resources:
- name: product
fields:
title: str
price: float
note: str? # trailing ? marks the field optional
auth: true # protect this resource's routes
Each entry under resources becomes a full CRUD resource: a database model,
request and response schemas, and the routes to create, read, update, and
delete it.
Generate and run
fullapi gen # api.yaml -> ./app
pip install -r requirements.txt
uvicorn app.main:app --reload
gen writes a working FastAPI project into ./app (or wherever you point
-o). At this point you have a normal FastAPI codebase: read it, extend it,
add your own routes alongside the generated ones.
Keep it honest
As the project grows, the code and the spec can drift apart. Someone renames
a field, drops a route, or makes something required without touching
api.yaml. check catches that:
fullapi check # exits non-zero on breaking changes
Wire it into CI and a spec/app mismatch fails the build instead of shipping quietly.
Commands
| Command | Description |
|---|---|
fullapi init [spec] |
Write a starter api.yaml |
fullapi gen [spec] [-o dir] |
Generate the project from the spec |
fullapi check [spec] [--app app.main:app] |
Fail on breaking drift from the spec |
How check works
It imports your live app and calls its real app.openapi() method, the same
schema FastAPI would serve at /openapi.json, then compares that against
what api.yaml says should exist. A route or field that disappeared, a type
that changed, or a field that became required without a matching spec
change: all of that counts as breaking and exits non-zero. New routes and
new optional fields are safe and don't fail the build.
Built and maintained by @sahilnyk.
Metadata
Release files for fullapi 2.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| fullapi-2.1.2.tar.gz | 16.3 kB | Without provenance | Details for fullapi-2.1.2.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| fullapi-2.1.2-py3-none-any.whl | Python 3 | none | any | Details for fullapi-2.1.2-py3-none-any.whl |
Total release size: 34.0 kB
Release files / fullapi-2.1.2.tar.gz
| Download URL | fullapi-2.1.2.tar.gz |
|---|---|
| Size | 16.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c9cf4735beeeea423b22d571612ae13b29bbfd00bfb65bda1af1cba84b78ef88
|
|
BLAKE2b-256 checksum How to use checksums |
f11e374846e2583be10fc019791435050828e61e6ec1bf9c167c577e756c9657
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.10.12
|
Release files / fullapi-2.1.2-py3-none-any.whl
| Download URL | fullapi-2.1.2-py3-none-any.whl |
|---|---|
| Size | 17.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c06e31f02e8d1a75628cd634101f636ab2811ec45a5cdd2abb3703e10476d04b
|
|
BLAKE2b-256 checksum How to use checksums |
dc8fa024fd95349394decba6eaeadad0374e6ca44a67a22a5ebcfcd15c65224b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.10.12
|
Security for fullapi 2.1.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.