Bienvenida

1

Todo lo que aprender谩s sobre Django

Cimientos

2

Arquitectura de una aplicaci贸n

3

The Twelve-Factor App

4

Codebase: Settings modular

5

Codebase: Dependencias y archivos de docker

6

Codebase: Docker

7

Setups alternativos

Modelos

8

Herencia de modelos

9

Proxy models

10

App de usuarios

11

Organizando modelos en un paquete de Django

12

Creando el modelo de perfil de usuario

13

Soluci贸n del reto: arreglando la migraci贸n de users a user

14

Aplicaci贸n y modelo de c铆rculos

15

Migraciones y admin de c铆rculos

Introducci贸n a Django REST Framework

16

Aprende c贸mo construir tu propio API con Django Rest Framework

17

Vistas, URLs y Parsers de DRF

18

Serializers

19

Buenas pr谩cticas para el dise帽o de un API REST

20

Request, response, renderers y parsers

Real DRF

21

Autenticaci贸n y tipos de autenticaci贸n

22

APIView

23

Creando el token de autorizaci贸n

24

User sign up

25

Limitar login a usuarios con cuenta verificada

26

Configurar env铆o de email

27

Instalar PyJWT y generar tokens

28

Verificar cuenta usando JWT

29

Actualizar modelo de circle (membership)

30

Crear CircleViewSet

31

A帽adiendo autorizaci贸n y paginaci贸n

32

Creaci贸n de circulos

33

Update de c铆rculo, custom permissions y DRF Mixins

34

Migraci贸n de vistas de usuarios a ViewSets

35

Detalle de usuario

36

Update profile data

37

List members - Recursos anidado

38

Retrieve destroy member

39

Modelo de invitaciones y manager

40

Obtener invitaciones de un miembro

41

Unirse a grupo

42

Filtrado

43

App de rides y modelos

44

Implementar la publicaci贸n de un ride

45

Validaci贸n de campos de un serializer

46

Listado de rides

47

Editar un ride

48

Unirse a viaje

49

Terminar viaje

50

Calificar viaje

Tareas as铆ncronas

51

驴Qu茅 es Celery?

52

Creando tarea as铆ncrona

53

Creando tarea peri贸dica

Testing

54

Python unittest y Django TestCase

55

DRF APITestCase

Django Admin

56

Admin actions: Modificar datos de un query

57

Admin actions: Regresando una respuesta HTTP

Deployment

58

Instalaci贸n de la aplicaci贸n

59

Configuraci贸n del dominio en Mailgun y del Bucket en Amazon S3

60

Configuraci贸n final de Docker Container usando Supervisor

61

Tutorial de despliegue de la aplicaci贸n

62

Futuros pasos y cierre del curso

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Serializers

18/62
Recursos

Los serializers son contenedores que nos permiten tomar tipos de datos complejos, convertirlos en datos nativos de python para despu茅s poderlos usar como JSON o XML. Son contenedores que amoldan datos para que cumplan con las condiciones de los serializers y sean llevados a un tipo de estos y despu茅s estos puedan ser transformados en otra cosa.

Aportes 13

Preguntas 4

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Iba a preguntar 驴Por qu茅 Pablo hace

from rest_framework import serializers

en lugar de

from rest_framework.serializers import Serializer

?
Pero ca铆 en cuenta que Pablo usa los Fields dentro de serializers y me di cuenta que muchas veces por eso es importante traer todo el m贸dulo xD

Por lo que entiendo estos archivos son una base donde se realiza toda la configuraci贸n general, si es as铆 entonces estos archivos los puedo usar para cualquier otro proyecto??
O sea a煤n no comienza a realizar las aplicaciones particulares del proyecto, no??

Por lo que entendi aqu铆 esta mostrando toda la configuraci贸n base para el proyecto y que puede servir para cualquier proyecto.
Si es as铆 entonces puedo usar todo estos archivos para otro proyecto???
Esto esto as铆 o estoy equivocado??
Saludos

Si uno hace buen uso de los fields en el modelo, no es necesario reescribirlos en el serializer. se puede usar Modelserializer para que los field usados en el serializer sean iguales a los del modelo:

from rest_framework.serializers import ModelSerializer
from profiles.models import Profile


class UserSerializer(ModelSerializer):
    class Meta:
        model = Profile
        fields = ('__all__')

me quedaron un par de dudas en el serializer ya que no me queda muy claro la diferencia entre poner el serializer con data Serializer(data=tu_objeto) a pasarlo sin el data Serializer(tu_objeto). cuando se manda data puedo hacer uso de is_valid pero si no lo paso no 鈥 como puedo validar cuando no le paso data= ya que si intento serializar una tupla si mando data debe ser un array pero sin data puedo mandarlo sin problema pero no puedo usar la funcion is_valid()

Tengo entendido que uno de los principios de Django y Python en general es DRY, evitar repetirse.

Ahora, veo que agregar validadores a nivel de la vista a trav茅s de los Serializers se hace para evitar que la validaci贸n llegue al modelo y sea propagada de vuelta a la vista, pero al mismo tiempo estamos duplicando la definici贸n de la validaci贸n de los campos.

Entonces, entiendo que para este caso, esta duplicidad implica muy poco riesgo de tener que actualizarla de forma constante, ya que cambiar validaciones de modelos y/o modificar columnas de una tabla no es una acci贸n demasiado frecuente. Entonces por la parte de DRY, creo que es muy aceptable romperlo un poco aqu铆.

Pero lo que no comprendo a煤n, es, 驴qu茅 ventajas nos ofrece el que la validaci贸n no llegue hasta el modelo? Mi intuici贸n me dice que al hacerlo de esta forma es m谩s f谩cil trabajar con Django RestFramework.

No estoy muy seguro, 驴ustedes que piensan?

DRF es excelente, que manera de ahorrar tareas tan repetitivas en la creacion de una API

Algun simil a este proyecto pero con MYSQL??

Es hermosooooo DRF. 馃槏

<h3>Serializers</h3>

In computing, serialization or serialisation is the process of translating a data structure or object state into a format that can be stored or transmitted and reconstructed later.

CreateCircleSerializer code

CircleSerializer code