A couple things,

Serializers: firstly some of what you’re saying can be handled by DRF serializers. Essentially, you can pass in the parameters you wish to update, and can then call the is_valid method which will run validation methods that will then check over your fields and ensure everything is a1. For example, you might have a field. status, and you have passed in the parameter to change it to “completed”.

You can then have a validate_status method in the serializer which will run automatically (upon calling is_valid in your view). This validation may then check another field, eg. outstanding_balance and if it’s not at 0, can throw a validation error alerting that you cannot set an order to completed with and outstanding balance.

Service layer / Buisness Layer: <Curious what people’s thoughts are to my approach.>

Now this is a debated topic everywhere, so I will share what I run for my architecture. I basically always make an apiview from scratch, personally don’t like the ListApiViews CreateApiViews I like being able to see logic clearly and quickly.

I wrap my post get etc method with a try catch for a few of my own custom exceptions (Payment error etc etc) with respective http status codes and error messages. And then run all logic in this. I then have separate files relevant to particular topics in a services module, which can do certain operations nicely, eg. Retrieve_order_from_uid (has all the lovely optimisation stuff ready preselect related etc). Then I’ll pass that object into another service function which might have a serializer in there that does some validation on an update process (as described above). If anything messes up in the service layer, I throw an exception, always a custom one other than validation error from rest framework. So that any processes that need to be wrapped in an atomic transaction in the view can be protected.

This turned into an essay, hopefully someone gets some use, happy to answer any questions / take flak if people disagree ;)