python - example - post serializer django

¿Cuándo se crean y se llaman las actualizaciones en el serializador djangorestframework?

Question

Actualmente estoy implementando djangorestframework para mi API RESTful de la aplicación. Después de jugar con ello, todavía no entiendo claramente qué .create(self, validated_data) y .update(self, validated_data) utilizados en el serializador. Según tengo entendido, CRUD solo llama a los 4 métodos principales en viewsets.ModelViewSet : create() , retrive() , update() y destroy() .

También he intentado depurar e imprimir cosas para ver cuando se .create() los .create() y .update() en ModelViewSet y ModelSerializer . Aparentemente, solo se llaman los métodos en ModelViewSet cuando hago los verbos HTTP. Sin embargo, para ModelSerializer , no veo ninguna llamada en esos 2 métodos. Solo quiero saber cuáles son esos métodos utilizados en ModelSerializer ya que veo que las personas anulan mucho esos métodos en el serializador.

P / S: soy un novato en djangorestframework + lo siento por mi inglés ya que no soy nativo.

Gracias :)

Answer 1

En el diseño de api-rest crear, leer, actualizar y eliminar es un estándar. No hay una gran diferencia en crear y actualizar.

Por favor refiérase a esto y

ver el método create () creará un elemento.

y

El método update () necesita especificar qué elemento se actualizará.

Answer 2

Finalmente entiendo cómo funcionan los .create() y .update() en Serializer (especialmente ModelSerializer ) y cómo están conectados a Viewsets (especialmente ModelViewSet ). Solo quiero aclarar el concepto más claramente si alguien llega a esta pregunta.

Básicamente, los 4 métodos CRUD en ModelViewSet : .create() , .retrieve() , .update() y .destroy() manejarán las llamadas de los verbos HTTP. De forma predeterminada, los .create() y .update() de ModelViewSet llamarán a .create() y .update() desde ModelSerializer llamando al método .save() de la clase BaseSerializer.

El método save () determinará si llamará a .create() o .update() en ModelSerializer determinando si el objeto self.instance existe o no.

Answer 3

Realmente debe dividir las cosas entre las vistas y el serializador.

Serializadores

El Serializer es un objeto independiente. Se utiliza para convertir un modelo de Django (o cualquier tipo de estructura de datos de python, en realidad) en una forma serializada, y viceversa. Puede usarlo como tal, donde quiera. Ni siquiera necesita una solicitud HTTP real, siempre y cuando no necesite URI en su salida.

La subclase ModelSerializer es un tipo especializado de Serializer que agrega la funcionalidad "cargar desde el modelo" y "guardar en el modelo". El punto de entrada "guardar en el modelo" es el método save() . Para una anulación más fácil, su implementación predeterminada delegará su trabajo en el método create() o update() del serializador, dependiendo de si está creando una nueva instancia de modelo o actualizando una.

El objetivo de esto es la personalización: le brinda a usted, el desarrollador, la opción de anular solo el método de creación, solo el método de actualización o el comportamiento común. Por ejemplo, te permite hacer este tipo de cosas:

def save(self, **kwargs):
    # Will be done on every save
    kwargs[''last_changed''] = timezone.now()
    return super().save(**kwargs)

def create(self, instance, data):
    # Will only be done if a new object is being created
    data[''initial_creation''] = timezone.now()
    return super().create(instance, data)

Ese es un ejemplo básico. Allí, el last_changed campo last_changed se establecerá cada vez que se guarde un objeto, ya sea una creación o una actualización. Como nota al margen, probablemente no quieras hacer eso. Cosas como la configuración de los campos "last_changed" deberían estar en la vista, no en el serializador.

Viewsets

En un lugar completamente diferente, el marco Django REST suministra Viewsets . Esas son una colección organizada de puntos de vista, que giran en torno a la implementación de una API CRUD para un modelo. Como tal, estructura su funcionalidad en un conjunto de métodos, a saber, create() , retrieve() / list() , update() y delete() .

El punto principal es que no hay conexión alguna entre el método create() viewset y el método create() del serializador.

Simplemente sucede que la implementación predeterminada de los métodos del viewset usa un ModelSerializer y que la implementación predeterminada del método save() del serializador delega el trabajo en métodos que tienen el mismo nombre.

Por cierto, sobre el last_changed ejemplo last_changed , aquí está cómo lo haría en la vista:

def perform_create(self, serializer):
    now = timezone.now()
    serializer.save(initial_creation=now, last_changed=now)

def perform_update(self, serializer):
    serializer.save(last_changed=timezone.now())

Eso es funcionalmente equivalente al ejemplo anterior, pero vive en el conjunto de vistas.

Conclusión

Así que de vuelta a su pregunta, lo específico que debe sobrescribir depende de qué objeto es responsable de la tarea que desea agregar.

• Si su comportamiento personalizado es parte del proceso de serialización, es decir, el proceso de convertir los datos sin procesar a un modelo Django apropiado y guardarlos, entonces debe anular los métodos del Serializer .
• Si, por otro lado, su comportamiento personalizado es específico para su viewset, entonces debe anular los Viewset del Viewset .

Como sugerencia, puede hacerse la siguiente pregunta: si utilizo el mismo serializador en otro lugar (tal vez otro viewset), ¿siempre debería mostrar ese comportamiento?