I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transa

I think making requests more atomic is pretty easy, if a bit painful--just make ATOMIC_REQUESTS=True the default, and rewrite get_or_create to occur in a transaction and perform a second get if it creates a new object, then rollback the transaction if more than one object is returned and use the other object instead (similarly rewrite update_or_create). I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms. I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it. For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.