Replies: 1 comment
-
I think this is just because you can use Personally I'm a fan of verbose schemas and recreating them often for different endpoints. Especially as your api grows in complexity it becomes difficult to have one schema for plates and one for experiments etc. We're moving away from this approach and django rest framework. It's a real breath of fresh air since everything is just much more clearly defined. In terms of naming, if you need a specific schema for a specific endpoint like I agree though it does get unwildy quite quickly. But that is the downside to working within python 🤷 it would be great to be able to define anon schemas like when defining typescrip types |
Beta Was this translation helpful? Give feedback.
-
I'm quite new to REST development and
django-ninja
, but I am enjoying it so far. My application is becoming more complex and I have some questions on how to organize schemas. Let's say I have the following models:Summarized, A
project
can have manyexperiments
, andexperiment
can have manyplates
, aplate
can have manywells
and awell
can have manywell_contents
.As a bit of a preface, I had read somewhere that it is bad practice to use
Optional
when defining schemas, so I tried not to do this wherever possible. Maybe this is not a totally correct approach though.The schemas start to get messy when I create views to return different formulations of my data. Let's say I have a endpoint that returns a plate and it's contents. The schemas might look like this:
This works fine, but this returns quite a lot of data, so I don't always want to return it. Let's say now I want to return all
plate_id
s for a givenexperiment
. I might have something like this, where I have a truncated version of my originalplates
schema:And now let's say I need to create plates, so I have another schema that maps to a plate input, without the
id
:So now I'm left with 3 schemas that are related to
plates
and this is only the beginning of fetching and creating data. It already seems quite messy to me. I'm finding naming hard as well.One solution I was thinking of is using
Optional
fields and fully describing each model with a schema and then truncating the data returned from models, but I'm not sure if that is a best practice.Thanks for reading, really just looking for any advice on schema organization/naming conventions for a more complex REST API.
Beta Was this translation helpful? Give feedback.
All reactions