I've been making APIs in django for years and for each project, at some point the API behaviour needs to differ from the model. It is not clear from the README how would one handle that use case.
That's the one reason I'm credited as an early contributor to Django-REST-Framework: suggesting to the author early on that he split DB model from API model
One thing I’ve never gotten about DRF’s model of using a Serializer is that it very quickly becomes overloaded with responsibilities: serializing and deserializing, validating request and response data, even updating an ORM model directly and bypassing the ViewSet entirely.
In my experience this leads to business logic getting littered all over a code base, and sometimes being inconsistent, mostly because a strong service layer doesn’t exist like in other frameworks I’ve used.
It is likely that I am just thinking about it incorrectly, or porting over my own expectations from other frameworks onto Django/DRF. Is there a better way to think about it?
those I think are optional conveniences, you can use less "smart" abstractions and do those things more explicitly. if I recall. I try not to use python/django anymore, too painful.
Are you referring specifically to separating the Serializer from the Model?
Do you have links to that convo? I love to read how design choices like that are made, and obviously that is one of the defining (correct) choices for DRF.
it was a DM on Convore in 2011 so it is long gone. my name is also only credited in an old CREDITS file in the DRF git history (not sour grapes, just explaining where these credits are)
I shared a prototype REST framework I'd built that separated Serializer from Model as inputs to views, yes, under different names, and he liked the idea and took it from there
this is the prototype repo: https://github.com/aehlke/django-catnap you can see the RestResource, RestModelResource classes. this was distinct from tastypie's approach (popular at the time)
Neat story! I design physical consumer goods products, and love seeing something I've worked on pop up into my "real life". Not being much of a programmer, do you think there's an equivalent feeling for coding? And was this one of those instances? I'll be honest, I'm getting 50/50 mildly entertained/mildly bitter vibes off your comment but only replying out of curiosity. Like I said, the intuitive understanding of "code" as a craft is somewhat foreign to me.
oh I'm glad someone else took the idea and made it work. I'm very glad to avoid the work that it took to build Django-REST-Framework :) I only prototyped my work originally because I couldn't find such a solution, not because I actually wanted to work on one.
I just couldn't tolerate tastypie, and I was sick of people learning from Rails to design thin wrappers over their data models for APIs (because of how easy Rails made that), I wanted people to move on from coupling data layer to API representations in such a 1:1 way as the default.
No affiliation to the project, but isn't it? It shows 'input' and 'output' schemata explicitly declared, which happen to match the model in the simple example, but could presumably be different (otherwise what's the point of them).
Agreed it's not super clear. But if you look where the ViewSet is defined, there is a regular function based route at the bottom. I'm pretty sure the idea is if your create method needs a different input schema for example, you just remove the `create_view = views.CreateModelView()` line and drop back to a regular function based Ninja view. This is similar to DRF how you can customize which methods your viewsets act on by listing out Mixins, but much more elegant (IMO).
