3 ms·

The model / model manager layer is the right place at which to design your state changing API. REST framework absolutely you to work with the grain there. Some

The model / model manager layer is the right place at which to design your state changing API. REST framework absolutely you to work with the grain there. Some good practice I'd recommend... * Write the `create()` and/or `update()` methods explicitly on the serializer class. * Push logic into the model and model manager where possible and only have the serializer `.save()` as a thin layer on top of that. That way a serializer class still has all the behavior it needs to map both ways between persisted objects and their corresponding native python representations, but you still have a well separated model API.

skatenerd 12y ago
Interesting. In practice, I have started following a pattern where I have two Serializer classes - a "serializer" and a "deserializer". The "deserializer"'s job is to perform validation and type coercion of incoming requests. It returns a "native" dictionary, which the application code then saves to ORM. The "serializer" is basically a presentation layer. It calls out to other nested serializers [this is awesome!], and it throws in convenience-fields that make the API response easier to consume. This pattern makes it a little bit less "magical", and it's easier to distinguish between the API's "incoming" behavior and its "outgoing" behavior.