Other librariesΒΆ
The following other Flask extensions are avaible for REST-functionality, they have been considered before creating this extension:
- Flask-Restless, does solve a slightly different problem, with fairly tight coupling.
- Flask-REST. Best name, no longer under development (at the time of this writing, hasn’t been for two years). Usage seems fairly clumsy with a lot of classes being thrown around.
- Flask-Restful seems to be the best of the bunch and in active development with many contributors. Lots of docs and apparently production usage/testing.
So why not use Flask-Restful? The following points describe what Flask-arrest tries to do better than Flask-Restful:
- Being Flask-y. Using classes instead of decorated function for routes looks
fairly alien in a Flask application, yet all other extensions seem to want
to force this for the obvious OO-abstraction. Flask-arrest uses routes,
view, the
methodsparameter. This means no new code and no new idioms (e.g. url_for just works), everything instantly recognizable by experienced (and novice) Flask-developers. - Using Blueprints. Should be a part of “being Flask-y” (see above), but is important enough to warrant its own mention. Again, saves code, makes stuff recognizable instantly and uses well-known Flask idioms. Also allows easily putting the API endpoints onto the app with any prefix.
In addition, it should be possible to easily implement the three levels of REST- Apis. All the mentioned REST-extensions seem to go up only to level 2, stopping short of Hypermedia Controls (HATEOAS); at the very least they are not including them in examples. Another missing feature (“missing” not meaning impossible-to- do, but not a first-class feature) seems to be content- negotiation, especially if unconventional or vendor-specific content-types are desired.
