How to build an API where the endpoints don't quite match the underlying database schemata?

[JI Ioannidis]

The tutorial, and pretty much everything else I have found, assumes that the models defined in models.py map one-to-one to database tables. I need to build an API for a service that uses the database, of course, but the endpoints I want to present do not correspond to the database tables. Can someone point me to where in the documentation this would be covered? FWIW, the database is Postgres, so I can't create views for that, as views are not mutable in postgres.

Examples of what I would want:

• There is a table foo with a uuid as the primary key, and another table fooextension with a foreign key pointing to foo.uuid. I was able to hack around that by adding an id field in fooextension, but that's about the limit of the modifications I can make to the database.
  
  
• There are many-to-many mappings handled with a map table: classical example is student and teacher; each has a .uuid field, and there is a map table defined as:
  
  

CREATE TABLE student_teacher_map( 

  student_uuid UUID REFERENCES student(uuid),

  teacher_uuid UUID REFERENCES teacher(uuid),

  UNIQUE(student_uuid, teacher_uuid)

);

how do I get my models to use this?

• I also need to create models where the various fields come from different tables, but they should be viewed and changed all together. 

Are all these things doable in DRF? They are definitely Turing-computable :)

I can't be the first person who ever had this problem, but search engines are not being very helpful here. 

Thanks,

/ji

[Xavier Ordoquy]

Hi,

Le 23 janv. 2018 à 00:57, JI Ioannidis <jay...@gmail.com> a écrit :

The tutorial, and pretty much everything else I have found, assumes that the models defined in models.py map one-to-one to database tables. I need to build an API for a service that uses the database, of course, but the endpoints I want to present do not correspond to the database tables. Can someone point me to where in the documentation this would be covered? FWIW, the database is Postgres, so I can't create views for that, as views are not mutable in postgres.

Anything that’s before ModelSerializer in http://www.django-rest-framework.org/api-guide/serializers/ applies to non model serialization.

Same goes for step 1 of the tutorial before « Using ModelSerializer ».

A huge part of the documentation covers ModelSerializer because it has more options since introspection can infer a lot from the model. Regular Serializer requires more to be done by the developer because it does not assumes much.

Examples of what I would want:

• There is a table foo with a uuid as the primary key, and another table fooextension with a foreign key pointing to foo.uuid. I was able to hack around that by adding an id field in fooextension, but that's about the limit of the modifications I can make to the database.
  
  
• There are many-to-many mappings handled with a map table: classical example is student and teacher; each has a .uuid field, and there is a map table defined as:
  
  

CREATE TABLE student_teacher_map( 

  student_uuid UUID REFERENCES student(uuid),

  teacher_uuid UUID REFERENCES teacher(uuid),

  UNIQUE(student_uuid, teacher_uuid)

);

how do I get my models to use this?

That’s a long standing issue with Django. A couple of years (Django < 1.4) ago I was able to get it working with some hacks. Would probably use explicit SQL nowadays.

• I also need to create models where the various fields come from different tables, but they should be viewed and changed all together. 

That’s were a you should drop ModelSerializer and deal with the mapping yourself because there will be a lot of specific logic to be added.

Are all these things doable in DRF? They are definitely Turing-computable :)

You may want to read how to create a DRF API without models at https://medium.com/django-rest-framework/django-rest-framework-viewset-when-you-don-t-have-a-model-335a0490ba6f

I can't be the first person who ever had this problem, but search engines are not being very helpful here. 

Thanks,

/ji

--
You received this message because you are subscribed to the Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JI Ioannidis]

This was tremendously helpful. Thanks.

/ji