Eve: the REST framework whose pitch is that you should not have to learn REST

Three lines to a live API

The pitch is that the whole thing starts with three lines of Python.

from eve import Eve

app = Eve()
app.run()

And then the API responds.

The README states what you actually need to bring: a database, a configuration file which defaults to `settings.py`, and a launch script. That is the entire operational surface. There is no project generator, no directory convention to memorise and no decorator to remember.

The project's own slogans appear in two different places and they are not quite the same. The GitHub description says REST API framework designed for human beings. The packaging metadata in `setup.py` says Python REST API for Humans, with the capital H. The README body says Eve is an open source Python REST API framework designed for human beings. Which of those you see depends on where you happen to look, and all three mean the same thing: the design target is a developer who knows what a REST API is and does not want to spend a month building one.

The framework is powered by Flask, which matters more than it first appears. Anything you know about Flask applies, and anything you want to add that Eve does not provide is a Flask extension or a blueprint.

Thirty-five features, and the four that decide whether you need it

The feature list is long and unordered, which is its own kind of documentation problem. Reading it for what it implies rather than what it says, four items stand out.

Read-only by default is the one that changes how you think. An endpoint is not writable until you make it writable, so a typo in a client cannot destroy data. That is a security property, not a convenience, and very few comparable frameworks default this way.

Data integrity and concurrency control means optimistic locking. Eve can reject a write whose document version no longer matches what the client read, which is the difference between a lost update and a caught conflict.

Document versioning and API versioning are separate features in the list, and they solve different problems. Document versioning is the mechanism underneath concurrency control. API versioning is about serving old clients: you can pin a URL to a version of your resource schema so a mobile app that has not been updated in six months keeps working.

Then there is MongoDB aggregation framework support, which tells you the framework leans into Mongo rather than abstracting it. Combined with the note that SQL backends exist via community extensions rather than in core, the shape of the project is clear: MongoDB is the first-class path and everything else is a port.

The rest of the list is broad but conventional: full CRUD, customisable and multiple item endpoints, filtering, sorting, pagination, HATEOAS, JSON and XML rendering, conditional requests, bulk inserts, data validation with an extension point, resource-level cache control, predefined database filters, projections, embedded resource serialisation, event hooks, rate limiting, custom ID fields, file storage, GeoJSON, internal resources, enhanced logging, an operations log, CORS and JSONP.

Dependencies: four libraries, and one that does the real work

The `setup.py` dependency list is short enough to see the design in.

INSTALL_REQUIRES = [
    "cerberus>=1.1,<2.0",
    "events>=0.3,<0.4",
    "flask",
    "pymongo",
    "simplejson>=3.3.0,<4.0",
]

`cerberus` is the validation engine, and everything in the list about data validation, schema, custom validators and defaults is Cerberus underneath. If you have used Cerberus directly, Eve's validation section will look familiar. If you have not, it is worth an hour on Cerberus alone, because you will be writing schemas either way.

`events` provides the event hook system, which is how you extend behaviour without subclassing anything: subscribe to pre-insert or post-update and run your own code. `pymongo` is the MongoDB driver, which means you are inside the driver's API surface whenever you need something the framework does not expose. `flask` is the web layer. `simplejson` is there for JSON handling with non-ASCII and decimal precision, which is a small detail that tells you the project cares about JSON edge cases.

There are two extra dependency groups. `docs` pulls sphinx, alabaster and doc8, and `tests` pulls redis, testfixtures, pytest and tox. The presence of redis and testfixtures in the test group is a tell: those are for testing rate limiting and caching without external services. The `dev` group is the union of both.

Note that `flask` and `pymongo` are unpinned, while the other three carry explicit bounds. Cerberus is capped below 2.0 and events below 0.4, which means the author expects breaking changes in both at the next major, and the bounds are there to stop pip taking them.

Running the tests and building the docs, from the Makefile

The Makefile is the best available answer to how this project is worked on, and it is small.

test: clean-pyc install-dev
	pytest

test-all: clean-pyc install-dev
	tox

The pattern is worth noting: every test target depends on `clean-pyc` and `install-dev`, and `install-dev` is an editable install with the dev extra. So a test run always reinstalls the package in editable mode with dev dependencies after removing stale bytecode. That is a slightly old-school workflow, and it is the one thing that would need modernising if you forked this.

`tox` runs the same thing across environments. The `docs` target shells into the `docs` directory and builds HTML into a `_build` directory, and the `docs-upload` target commits and pushes the built HTML, with a comment noting it is only useful on the maintainer's own machine.

Code style is handled by Black, configured in `pyproject.toml`, which is three lines long because Black needs almost nothing:

[tool.black]
safe = true
quiet = true

`safe` makes Black only apply transformations it considers semantically equivalent, and `quiet` suppresses the per-file chatter. There is a `.pre-commit-config.yaml` in the tree, a `pytest.ini`, a `tox.ini` and a `SECURITY.md`, which is a more complete project skeleton than the README suggests.

The maintenance picture, stated plainly

This is the part worth being careful about, because the README's funding section makes a claim that deserves a date attached to it.

The last push to this repository was on 2026-03-24. That is more than six months ago as of this writing. The repository has 6,745 stars, 738 forks and 29 open issues, and it is not archived.

The funding section asks sponsors to help ensure the project stays healthy and under active care, and that sentence is a funding appeal rather than a status report. It tells you the maintainer cares about continuity, not that continuity is currently guaranteed.

There is a second signal. The repository publishes no GitHub releases at all. Version history lives in `CHANGES.rst` in the tree, which is the right place for a library that predates release automation but means you have to read a changelog file rather than check a releases page to know when something last shipped.

The version is not hardcoded in `setup.py` either. It is read out of the package source with a regular expression at build time, which means the version lives in one place, in `eve/__init__.py`, and is extracted rather than duplicated.

The license is worth one more note because GitHub cannot classify it. The repository's license field comes back as unrecognised, while the README carries a BSD badge, `setup.py` declares `license="BSD"`, there is a LICENSE file in the tree, and the classifiers include the OSI-approved BSD license classifier. Four sources agree and one machine-readable field does not, so the project is BSD and the metadata detection is what failed.

Python support, stated two different ways

There is a small contradiction in the packaging metadata that you will hit the first time you install this.

`python_requires` says `>=3.7`. The classifiers list Python 3.9 onward, and the trailing entries are cut off in the metadata rather than ending at a version. So the declared floor and the tested versions disagree by two releases.

Which one is real depends on when the floor was last touched. A floor of 3.7 dates from before 3.7 itself was end of life, and the classifiers look like they were updated separately and more recently. The practical reading is that 3.9 is the oldest version anyone actually tests against, and the 3.7 floor is a leftover.

There is one other packaging detail that tells you about how this project is distributed. The long description is read from `README.rst` with content type `text/x-rst`, and there is an `AUTHORS` file, a `CONTRIBUTING.rst` and an `artwork/` directory in the tree. The presence of an artwork directory alongside a funding page is a sign of a project with an actual community around it rather than a bare code drop.

There is also a `response.md` at the repository root, which is unusual and worth opening if you are evaluating: it suggests a documented conversation about what the framework returns and how.

Editorial conclusion

Eve's design bet is that a REST API should be a configuration file rather than a project, and for a long time that bet paid off. You point it at a database, describe your resources, and you get CRUD with filtering, sorting, pagination, validation, authentication, rate limiting and versioning without writing a view. The cost is that you inherit Flask's mental model and MongoDB's data model, and the framework does very little to help you move off either. The maintenance picture deserves a straight answer: the last push to this repository was on 2026-03-24, more than six months ago, with 29 open issues and no GitHub releases to date the work by. Nothing is archived and nothing is marked deprecated, but the release history lives in CHANGES.rst rather than in releases, which makes it harder to tell you what changed recently. If you are starting something new in 2026, weigh that against Flask-RESTful, FastAPI or a plain FastAPI and SQLAlchemy setup. If you already have Eve in production, nothing in the repository suggests you need to move.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. pyeve/eve on GitHub
4. README