I've taken to using an intermediate 'service' layer (in the parlance, but not structure, of overholt) to manage metadata on fields and inform serialization. It looks a bit like Marshmallow, but baked in as a Flask extension.
I've been kicking around different approaches to this for over a decade, going back to Castor (Java data binding), and with Python, SQLAlchemy, and the libraries mentioned here I'm finally feeling optimistic.
Request parsing in Flask-RESTful seems bolted on, and the fields in WTForms seem frustratingly redundant given that almost everything I do is going through the API anyway. Maybe focusing more on the Fields themselves will help tie it all together.
Re:Reasons to love SQLAlchemy
by hurtmyknee on Thursday September 24, 2015 @11:00AM
(#10271980)
Flask-RESTful worked out for me, I like how easy it is to define routes. I'm eager to try Falcon next: http://falconframework.org/
I tried both flask-restless and restful as well, but like you have moved away from them to a simpler setup. Just using a simple flask app + blueprints with a few extra error handling / cors bits and a custom response class for json. I'm very happy with marshmallow too.
I recently created a new API and went for a very simple flask.Methodview along with Marshmallow [0] for (de)serialization. I then wrote a simple replacement for marshmallow-alchemy since it wouldn't do object loading without a lot of flapping about.
I found Marshmallow really nice to work with (I'd been using Schematics in the past).
[0] https://github.com/marshmallow-code/marshmallow