Django Rest Framework: de funciones a vistas genéricas

Clase 10 de 21 • Curso de Django Rest Framework

Resumen

Organiza y escala tus endpoints en Django Rest Framework con un refactor claro: pasa de vistas basadas en funciones a vistas basadas en clases (APIView) y luego simplifica con vistas genéricas como ListApiView y CreateApiView. Verás cómo el código se vuelve más limpio, reutilizable y fácil de mantener sin perder control.

¿Por qué migrar de funciones a vistas basadas en clases en Django Rest Framework?

Las vistas basadas en clases permiten agrupar lógica por método HTTP y aprovechar funcionalidades nativas de DRF. Además, simplifican la configuración de métodos permitidos, permisos y throttle, y añaden soporte automático a HEAD y OPTIONS.

Estructura clara: métodos get, post, put, delete separados por función.
Escalabilidad real: reutilización con herencia y clases padre.
Validación automática: allowed methods limita respuestas a los métodos definidos.
Más herramientas listas: permisos y throttle disponibles cuando se necesiten.
Mejor experiencia de cliente: HEAD obtiene solo headers rápidamente. OPTIONS informa campos y métodos disponibles.

¿Cómo refactorizar ApiView a clases en DRF?

Primero, importa la clase y crea tu vista basada en clases. Luego define los métodos HTTP y conecta la URL con as_view.

¿Cómo declarar la clase y métodos get/post?

from rest_framework.views import ApiView

class ListPatientsView(ApiView):
    allowed_methods = ['GET', 'POST']

    def get(self, request):
        # Copia la lógica de listado que usabas en la vista basada en función.
        pass

    def post(self, request):
        # Copia la lógica de creación del recurso patient.
        pass

Idea clave: allowed methods valida qué métodos responderán.
Beneficio: el recurso lista queda expresivo: GET lista, POST crea.

¿Cómo conectar la URL con as_view?

from django.urls import path
from .views import ListPatientsView

urlpatterns = [
    path('patients/', ListPatientsView.as_view()),
]

Usa as_view para obtener la vista ejecutable.
La interfaz navegable de DRF mostrará además HEAD y OPTIONS automáticamente.

¿Cómo convertir el detalle con get/put/delete?

from rest_framework.views import ApiView

class DetailPatientView(ApiView):
    allowed_methods = ['GET', 'PUT', 'DELETE']

    def get(self, request, pk):
        # Recupera y retorna el paciente por pk.
        pass

    def put(self, request, pk):
        # Actualiza el paciente por pk.
        pass

    def delete(self, request, pk):
        # Elimina el paciente por pk.
        pass

Al refactorizar notarás duplicación de consultas para obtener el objeto.
Señal de mejora: extraer una función auxiliar o pasar a vistas genéricas.

¿Qué simplifican las vistas genéricas ListApiView y CreateApiView?

Las vistas genéricas ya traen implementados los métodos estándar de REST. Solo defines serializerClass y QuerySet, y DRF se encarga del resto. Así reduces tu vista de lista y creación a pocas líneas.

from rest_framework.generics import ListApiView, CreateApiView

class ListPatientsView(ListApiView, CreateApiView):
    serializerClass = PatientSerializer
    QuerySet = Patient.objects.all()

serializerClass: indica cómo serializar y validar los datos.
QuerySet: especifica de dónde obtener los elementos a listar o crear.
Efecto inmediato: puedes borrar el get y el post manuales.

Además, en la interfaz navegable puedes alternar entre HTML form y raw data para enviar JSON; DRF incluso muestra un datetime picker para fechas. Si más adelante necesitas personalizar comportamiento, ya sabes qué método sobrescribir porque entendiste el flujo manual primero.

Conceptos fortalecidos: ApiView, allowed methods, as_view, ListApiView, CreateApiView, DestroyApiView, serializerClass, QuerySet, permisos, throttle, HEAD, OPTIONS, frontend, raw data.
Habilidades prácticas: refactor paso a paso, herencia múltiple de vistas genéricas, eliminación de duplicación, uso de la interfaz navegable para probar endpoints.

¿Te animas a dar el siguiente paso? Implementa el detalle con vistas genéricas y comparte tu código en comentarios para recibir feedback.

Germán Salina

student•

Este profesor no Decepciona 👏👏

Luis Martinez

teacher•

Gracias por tu comentario! Espero que estés disfrutando el curso

kolab Linkear

student•

Un aspecto clave de Django Rest Framework es que ofrece herramientas muy útiles que simplifican el desarrollo. A diferencia de otros frameworks donde es necesario implementar muchas funcionalidades manualmente, DRF te permite optar entre hacerlo a mano o aprovechar sus características integradas. Esto facilita la creación de aplicaciones completamente personalizadas y flexibles, adaptadas a las necesidades específicas del proyecto 🐍.

Andres Trujillo

student•

jesus manuel vergara arias

student•

Funciona solo haciendo esto...

Es increible que hasta el pk es abstraido...... Osea, si lees este código es casi imposible, sin saber lo que pasa por debajo, que esta vista hace get/put/delete sobre un id.

Ray Trápala

student•

Sí, viendo la definición de la clase tienen como "pk" el nombre del atributo para el id. Imagino por eso nos enseñaron a usar pk para el id en la url

Juan Camilo Jaramillo Tascón

student•

Profe, realicé el cambio de las vistas basadas en funciones con la clase APIView, sin embargo, no me aparece por defecto los métodos HEAD y OPTIONS, ni siquiera el HTML form, sabes qué podría ser? O alguien más sabe qué puede ser?

juan jose cardona gil

student•

estoy con la misma duda

Juan Camilo Jaramillo Tascón

student•

juan jose, al seguir el curso, cuando se utilizan los ViewSets se arregla el problema

Damian Rengifo

student•

Lo mas que pude simplificarlo fue en el siguiente codigo, use la clase RetrieveUpdateDestroyView ya que puede hacer ambas operaciones update y delete sin necesidad de especificar el allowed_methods

Luis Martinez

teacher•

Excelente! muy simple y útil saber como funciona!

Juan Camilo Jaramillo Tascón

student•

Increíble la simplificación que se realiza

Antonio Demarco Bonino

student•

Dejo un resumen, breve, de HEAD y OPTIONS:

HEAD: Se utiliza cuando solo necesitas los headers de una solicitud, sin el cuerpo (por ejemplo, para verificar la existencia o propiedades de un recurso).
OPTIONS: Te dice qué métodos HTTP son soportados por un recurso, útil para seguridad y manejo de políticas entre dominios (CORS).

Janice Naydelin Flores Garcia

student•

La simplificación del código realmente me impresiono.😎

Luis Martinez

teacher•

Es muy util ademas para evitar bugs al escribir menos codigo.

Yesica Alejandra Giraldo Tique

student•

Un endpoint es una URL específica que permite la interacción entre un cliente y un servidor en una API (Interfaz de Programación de Aplicaciones). En el contexto de Django REST Framework, un endpoint define cómo se pueden acceder a los recursos a través de métodos HTTP como GET, POST, PUT o DELETE. Cada endpoint se asocia a una vista que maneja las solicitudes y respuestas, facilitando la comunicación y el intercambio de datos en aplicaciones web.

Jonathan Mauricio Meza Bastidas

student•

En Django REST Framework, las vistas basadas en funciones (FBV) son útiles cuando se necesita algo rápido, simple y directo. Se suelen usar para endpoints muy básicos que solo manejan una o dos operaciones, como un GET de prueba o un endpoint de estado. Son fáciles de entender y escribir, por lo que resultan convenientes en prototipos pequeños o cuando la lógica no va a crecer demasiado.

Por otro lado, las vistas basadas en clases (CBV) ofrecen una estructura más organizada y sobre todo escalable. Gracias a la herencia, los mixins y los viewsets, no solo permiten manejar los métodos principales (get, post, put, delete), sino que también facilitan la creación de funciones personalizadas dentro de la misma clase, algo que en FBV sería más engorroso de mantener. Esta capacidad de extender y reutilizar código hace que las CBV sean la mejor opción para proyectos grandes o APIs que evolucionan con nuevas funcionalidades.

Miguel Angel Goda Molina

student•

Para los que tuvieron problemas vamos a dividir los problemas en dos partes primero porque no aparecen todo los metodos: El atributo allowed_methods describe los métodos que puede utilizar ese endpoint en concreto, como solo colocaste GET y POST, sobreescribiste los otros métodos por default que tiene esta vista, esto lo puedes comprobar comentando esa línea o añadiendo HEAD y OPTIONS al array de allowed_methods.

Para la segunda Parte sobre el motivo por el cual no te aparece la forma HTML en el propio endpoint cuando utilizas la vista basada en APIView es porque Django REST Framework no renderiza automáticamente formularios HTML para vistas basadas en clases genéricas como APIView o para métodos explícitos como get y post. Los formularios de la interfaz de navegación del API están disponibles únicamente cuando usas las vistas genéricas de DRF (CreateAPIView, DestroyAPIView, ListAPIView, etc.) o que utilizan el decorador @api_view, que está diseñado para manejar vistas basadas en funciones

Johan Moises Ariza Mahecha

student•

Con respecto al reto, mi vista quedaría de la siguiente manera:


class DetailPatientsView(RetrieveUpdateDestroyAPIView):
    allowed_methods = ['GET', 'PUT', 'DELETE']
    serializer_class = PatientSerializer
    queryset = Patient.objects.all()

Juan Camilo Grisales Arias

student•

Que buen curso.

Antonio Demarco Bonino

student•

Se los dejo aquí para que lo vayan probando:

# Define the ListPatientsView class with allowed_methods restriction
class ListPatientsView(APIView):
    allowed_methods = ['GET', 'POST']  # Only allow GET and POST methods

    # GET method to list all patients
    def get(self, request):
        patients = Patient.objects.all()  # Retrieve all patients
        serializer = PatientSerializer(patients, many=True)  # Serialize the data
        return Response(serializer.data)  # Return the serialized data in the response

    # POST method to create a new patient
    def post(self, request):
        serializer = PatientSerializer(data=request.data)  # Deserialize the request data
        serializer.is_valid(raise_exception=True)  # Automatically handle validation exceptions
        serializer.save()  # Save the new patient
        return Response(status=status.HTTP_201_CREATED)  # Respond with 201 Created without returning the patient data

Luis Antonio Del Rio Salguero

student•

class DetailPatientView(RetrieveUpdateAPIView):
    serializer_class = PatientSerializer
    queryset=Patient.objects.all()
    lookup_field = 'id'

Esta es la forma en la cual creemos que se podía optimizar.

Robert Yesid Barrios Acendra

student•

Al cambiar a vista basada en Clases, no me está mostrando ni el form, ni el json preescrito, ni el HEAD, ni el OPTIONS. ¿Qué sucede ahí?

Luis Martinez

teacher•

Compartenos el código para poder ayudarte por favor

Robert Yesid Barrios Acendra

student••

Si no estoy mal, se resolvió cuando dejé de usar la APIView y usé las de generics, creo que así fue que apareció todo lo que dije y el form en las 2 versiones: raw(json) y html. Pero en el video, te aparecen sin todavía haber usado las de generics.

Albert Pacheco Ospitia

student•

Me gustaria saber porque en python es común crear las clases en un solo archivo y no cada clase en cada archivo?

Luis Martinez

teacher•

Podria decir que son gustos, también es posible crear un archivo por class

Henry David Fajardo Lagos

student•

Las vistas basadas en funciones (FBV) y las vistas basadas en clases (CBV) en Django REST Framework tienen diferencias clave:

Estructura: FBV utiliza funciones simples para manejar las peticiones, mientras que CBV utiliza clases, lo que permite una organización mejorada y reutilización de código.
Escalabilidad: CBV es más escalable, ya que permite la adición de nuevas funcionalidades (métodos) mediante la extensión de la clase, mientras que FBV puede volverse más difícil de manejar a medida que crece la lógica.
Estandarización: CBV ofrece vistas genéricas que simplifican tareas comunes (como listar y crear), mientras que FBV requiere más código repetido para cada funcionalidad.

Utilizar CBV puede mejorar la mantenibilidad de tu código a largo plazo.

Juan Camilo Grisales Arias

student•

class PatientListCreateAPIView(ListCreateAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer


class PatientRetrieveUpdateDestroyAPIView(RetrieveUpdateDestroyAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer

Alvaro Emilio Dangond Rojas

student•

from rest_framework.generics import ListCreateAPIView, RetrieveUpdateDestroyAPIView
from .models import Patient
from .serializers import PatientSerializer

# GET /api/patients => Listar
# POST /api/patients => Crear
class ListPatientsView(ListCreateAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer

# GET /api/patients/<pk>/ => Detalle
# PUT /api/patients/<pk>/ => Modificación
# DELETE /api/patients/<pk>/ => Borrar
class DetailPatientView(RetrieveUpdateDestroyAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer
```from rest\_framework.generics import ListCreateAPIView, RetrieveUpdateDestroyAPIView

from .models import Patient

from .serializers import PatientSerializer



\# GET /api/patients => Listar

\# POST /api/patients => Crear

class ListPatientsView(ListCreateAPIView):

&#x20;   queryset = Patient.objects.all()

&#x20;   serializer\_class = PatientSerializer



\# GET /api/patients/\<pk>/ => Detalle

\# PUT /api/patients/\<pk>/ => Modificación

\# DELETE /api/patients/\<pk>/ => Borrar

class DetailPatientView(RetrieveUpdateDestroyAPIView):

&#x20;   queryset = Patient.objects.all()

&#x20;   serializer\_class = PatientSerializer

Carlos Rodríguez

student•

Tengo más de un año trabajando con Django y DRF, y el profesor explica cada detalle que hace que sea mejor que la documentación. Excelente curso.

# Define the ListPatientsView class with allowed_methods restriction
class ListPatientsView(APIView):
    allowed_methods = ['GET', 'POST']  # Only allow GET and POST methods

    # GET method to list all patients
    def get(self, request):
        patients = Patient.objects.all()  # Retrieve all patients
        serializer = PatientSerializer(patients, many=True)  # Serialize the data
        return Response(serializer.data)  # Return the serialized data in the response

    # POST method to create a new patient
    def post(self, request):
        serializer = PatientSerializer(data=request.data)  # Deserialize the request data
        serializer.is_valid(raise_exception=True)  # Automatically handle validation exceptions
        serializer.save()  # Save the new patient
        return Response(status=status.HTTP_201_CREATED)  # Respond with 201 Created without returning the patient data

class PatientListCreateAPIView(ListCreateAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer


class PatientRetrieveUpdateDestroyAPIView(RetrieveUpdateDestroyAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer

from rest_framework.generics import ListCreateAPIView, RetrieveUpdateDestroyAPIView
from .models import Patient
from .serializers import PatientSerializer

# GET /api/patients => Listar
# POST /api/patients => Crear
class ListPatientsView(ListCreateAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer

# GET /api/patients/<pk>/ => Detalle
# PUT /api/patients/<pk>/ => Modificación
# DELETE /api/patients/<pk>/ => Borrar
class DetailPatientView(RetrieveUpdateDestroyAPIView):
    queryset = Patient.objects.all()
    serializer_class = PatientSerializer
```from rest\_framework.generics import ListCreateAPIView, RetrieveUpdateDestroyAPIView

from .models import Patient

from .serializers import PatientSerializer



\# GET /api/patients => Listar

\# POST /api/patients => Crear

class ListPatientsView(ListCreateAPIView):

&#x20;   queryset = Patient.objects.all()

&#x20;   serializer\_class = PatientSerializer



\# GET /api/patients/\<pk>/ => Detalle

\# PUT /api/patients/\<pk>/ => Modificación

\# DELETE /api/patients/\<pk>/ => Borrar

class DetailPatientView(RetrieveUpdateDestroyAPIView):

&#x20;   queryset = Patient.objects.all()

&#x20;   serializer\_class = PatientSerializer

Django Rest Framework: de funciones a vistas genéricas

Fundamentos de Django Rest Framework

Django REST Framework para APIs escalables

Qué son las APIs y cómo funcionan

Configuración de Django REST Framework paso a paso

Django Rest: qué reutiliza de Django

Serializers Django: modelos a JSON fácil

Listado de pacientes con serializers en DRF

POST y GET en el mismo endpoint con Django REST

CRUD completo con PUT y DELETE en Django Rest

Cómo probar APIs con Postman y curl

Django Rest Framework: de funciones a vistas genéricas

Vistas genéricas en Django Rest Framework

Documentación automática de APIs con drf-spectacular

Vistas y Endpoints

ViewSets vs APIView: refactor automático de URLs

Acciones en Django Rest con decorador @action

Autenticación y permisos en Django Rest Framework

Validaciones custom en Django Rest Framework

Serializadores Avanzados

Serializadores anidados en Django REST Framework

Serializer_method_field para cálculos en Django REST

Endpoint anidado para agendar citas médicas

Testing y Desempeño

Unit tests con ApiClient en Django REST

Throttling en Django Rest para evitar ataques DOS