Recommended alternatives to Flask-RESTful components

[joshfriend]

As some folks have noticed, I don't work on this much anymore. This is mostly because I've found alternatives that I like better than what's provided here, so I don't actively use Flask-RESTful for any of my projects anymore.

Here's what I recommend for replacements in TL;DR form:

• Resource → Regular flask MethodView
• reqparse → webargs/Marshmallow
• fields → Flask-Marshmallow
• utils.cors → Flask-CORS
• utils.crypto → Nobody knows what this even does

Marshmallow in particular is a worthwhile change because it does so many things better than fields or reqparse:

• It can parse nested objects and lists from requests
• better type support
• It has better and more flexible validation
• better API in general. Schemas are objects that can inherit other schemas for composability

Regarding Resource I found that I did not need any of the wrapping that it and Api do. Just MethodView from Flask was plenty for any use case I found.

[ThiefMaster]

webargs might be a good choice for the request data parsing part as well (it's using marshmallow schemas internally and can also make use of them directly if you already have/need one anyway)

[joshfriend]

Ah yes, webargs. That's what I had meant to put down for request parsing but forgot it was a separate package from marshmallow, thanks.

[soberservicesguy]

@joshfriend Can you please mention what benefit did you get by using MethodView over Resource? or what issues you had with Resource that MethodView isnt having ?

[joshfriend]

I don't like Resource or Api's error handling and didn't need anything they did besides method dispatching.

Really the only thing I did want was ability to construct flask Response from a view method returning a dict or dict, 200 or dict, 200, {"some": "headers"}

I also wrote a very small Blueprint subclass that let me add methodviews to routes with a decorator:

@bp.endpoint("foo/bar")
class FooBarResource(MyResource):
    pass

but that was also very optional and only took like 5 lines of code

[soberservicesguy]

can you point out the differences in error handling in both?

[volbil]

@joshfriend thanks for your update, it was a pleasure to use Flask-RESTful in my projects :)

[jeryini]

I found flask-classful also a very good replacement for Resource/MethodView.

[joshfriend]

@soberservicesguy The current error handler is rather complicated, inflexible, and contains bugs as noted in numerous open issues/PRs:

• Use message from exception in custom error messages #274
• Error handling re-worked #544
• Add catch_all_405s or ability to define custom error handler for 405 MethodNotAllowed Error #579
• Exceptions thrown within Flask-RESTful apps getting executed instead of thrown? #582
• add callable for custom error message #787
• flask_restful.abort with a Response as an arg returns http status code 200 OK #794
• flask_restful.handle_error handles errors which have registered handlers in flask.app #796
• got_request_exception fires for 405 errors generated by flask-restful #802
• Is it possible to use only flask original error handler? #850

The way to have custom error messages for custom exceptions is also rather limited and generally not very useful.

I usually write my own version of abort() that can delegate to custom handler functions for the various status codes and exceptions that i might throw.

[aaj]

@jeryini can you speak to that a bit? I'm looking through my options and I think flask-classful is the best fit. My reason is because I need something super un-opinionated right now.

[jeryini]

Hello @aaj! Yes I found flask-classful a very good replacement for Resource. Together with other libraries mentioned here (e.g. marshmallow for serialization/deserialization) it's a great fit. In initial description of the project in documentation, maintainers of the project do state why it might be a better fit then to just use native Flask MethodView:

Well, yes and no. While flask.views.MethodView does provide some of the functionality of flask_classful.FlaskView, it doesn’t quite complete the picture by supporting methods that aren’t part of the typical CRUD operations for a given resource, or make it easy for me to override the route rules for particular views. And while flask.views.View does add some context, it requires a class for each view instead of letting me group very similar views for the same resource into a single class.

[miraculixx]

For me the best alternative to flask-restful has been flask-restplus, which is now flask-restx

[joshfriend]

A lot of flask-restplus/flask-restx is a direct copy of flask-restful, which is probably why you like it so much as an alternative 😉.

[Querela]

A lot of flask-restplus/flask-restx is a direct copy of flask-restful, which is probably why you like it so much as an alternative 😉.

I was wondering about that. Now it is clear why the docs are so similar. 🙄

[lafrech]

flask-restplus wanted to replace request parsing with marshmallow/webargs but never did it, mainly due to lack of time/motivation and not wanting to lose backwards compatibility. A user provided an example patching flask-restplus to use marshmallow but that never made it to the core. flask-restx didn't do it either.

This lack of marshmallow integration is the reason we wrote flask-smorest. It is marshmallow based, uses webargs for request parsing and apispec for doc generation.