4 ms·

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

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.

odiroot 3y ago
Yes, very common thing is to have some feel read-only but still appear in the response to POST/PATCH. Also the set of fields changing depending on the access level of the user (admin-only fields).
wahnfrieden 3y ago
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
- jamestimmins 3y ago
  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.
  - wahnfrieden 3y ago
    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 https://github.com/aehlke/django-catnap you can see the RestResource, RestModelResource classes. this was distinct from tastypie's approach (popular at the time)
    - jamestimmins 3y ago
      Excited to look, thanks for sharing!
    - digdugdirk 3y ago
      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.
      - wahnfrieden 3y ago
        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.
- oflannabhra 3y ago
  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?
  - wahnfrieden 3y ago
    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.
OJFord 3y ago
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).
WD-42 3y ago
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).

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.

odiroot 3y ago

Yes, very common thing is to have some feel read-only but still appear in the response to POST/PATCH. Also the set of fields changing depending on the access level of the user (admin-only fields).

wahnfrieden 3y ago

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

jamestimmins 3y ago
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.
- wahnfrieden 3y ago
  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 https://github.com/aehlke/django-catnap you can see the RestResource, RestModelResource classes. this was distinct from tastypie's approach (popular at the time)
  - jamestimmins 3y ago
    Excited to look, thanks for sharing!
  - digdugdirk 3y ago
    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.
    - wahnfrieden 3y ago
      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.
oflannabhra 3y ago
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?
- wahnfrieden 3y ago
  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.

OJFord 3y ago

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).

WD-42 3y ago

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).