Vistas genéricas en Django Rest Framework

Contenido del curso

Fundamentos de Django Rest Framework

Vistas y Endpoints

Serializadores Avanzados

Testing y Desempeño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:004:18

Vistas genéricas en Django Rest Framework

Curso de Django Rest Framework

Clase 11 de 21

Clase 11 / 21

Recursos

Optimiza tu API con confianza: las vistas genéricas de Django Rest permiten crear una vista de detalle que obtiene, actualiza y elimina un recurso, reduciendo código y errores. Aquí verás cómo pasar de lógica duplicada a una implementación clara y reutilizable.

¿Por qué usar vistas genéricas para el detalle?

Las vistas genéricas permiten obtener el objeto, modificarlo, borrarlo o mostrarlo como JSON sin escribir lógica repetida. En lugar de manejar manualmente el 404 por ID y repetir consultas, se hereda de una clase que ya incluye estas operaciones.

Menos código y menos duplicación.
Manejo automático de error 404 cuando el ID no existe.
Soporte integrado para métodos como GET, PUT y DELETE.

¿Cómo evitar código duplicado con vistas genéricas?

La clave es reemplazar el uso de ApiView por una clase que combine operaciones. En lugar de importar y usar por separado RetrieveApiView, UpdateApiView y DestroyApiView, se utiliza una sola clase que reúne todo: la combinada de retrieve, update y destroy.

# Vista de detalle simplificada (esqueleto)
class PacienteDetailView(RetrieveUpdateDestroyApiView):
    queryset = ...  # colección de pacientes.
    serializer_class = ...  # serializador del paciente.
    # Ya no se implementa get_object ni el 404 manual.

El resultado: el código “sigue funcionando perfectamente” y se eliminan bloques redundantes.

¿Qué diferencia hay entre las clases individuales y la combinada?

RetrieveApiView: obtiene un recurso.
UpdateApiView: actualiza un recurso.
DestroyApiView: elimina un recurso.
Combinada retrieve, update y destroy: incluye las tres funcionalidades en una sola vista. Si solo quieres permitir actualizaciones, importa únicamente la de update; si quieres todo, usa la combinada.

¿Qué variables hay que definir al heredar de la clase combinada?

Basta con “volver a definir estas mismas variables” ya usadas en la vista previa, típicamente las que indican la colección de objetos y el serializador. Con eso, no hace falta el código manual para buscar por ID ni devolver 404.

¿Cómo validar desde el navegador que todo funciona?

La verificación es directa: se accede al detalle de un paciente (por ejemplo, el ID 3) y funciona. Aparecen un botón de Delete y un formulario que permite editar; incluso es posible enviar cambios con raw data.

¿Cómo probar GET, PUT y delete desde el detalle?

GET por ID: obtener el recurso “tres” y ver su detalle.
PUT para actualizar: cambiar, por ejemplo, el correo a “Platzi” y recibir 200 con el nuevo valor reflejado.
DELETE: disponible con el botón del detalle.

¿Qué aportan los mensajes de error al front end?

Si envías un dato inválido (por ejemplo, una “fecha de nacimiento” no válida), al guardar se muestran mensajes de error claros. Esto es muy útil para el front end: explica por qué el request falla y qué campo corregir.

¿Qué mejoras aporta el formulario y el raw data?

Edición directa en el formulario del detalle.
Envío de cambios con raw data sin copiar y pegar.
Flujo más rápido para iterar sobre pruebas y validaciones.

¿Qué sigue: view sets y nuevos endpoints?

El siguiente paso es usar view sets para agrupar vistas sin repetirse, incluso cuando aún queden “dos líneas” duplicadas. Con el endpoint de pacientes ya listo usando vistas basadas en clases (tras el refactor desde vistas basadas en funciones), llega el momento de crear los endpoints de doctores y citas. Todo el código, muy parecido entre sí, estará disponible en el repositorio de recursos.

¿Por qué usar view sets para agrupar vistas?

Reducen repetición en configuraciones comunes.
Centralizan operaciones de lista, detalle, actualización y borrado.
Preparan la base para trabajar con varios endpoints sin reescribir lógica.

¿Te quedaron dudas sobre la migración a vistas genéricas o view sets? Comenta qué parte de tu API quieres simplificar y qué operaciones necesitas incluir.

Bastian Maurico Landskron Silva

Hace 2 años

from rest_framework import viewsets
from rest_framework.response import Response
from rest_framework import status
from .models import Cliente, Reserva, Historial
from .serializers import ClienteSerializer, ReservaSerializer, HistorialSerializer

class ClienteViewSet(viewsets.ModelViewSet):
    queryset = Cliente.objects.all()
    serializer_class = ClienteSerializer

    def retrieve(self, request, pk=None):
        """
        Sobrescribe el método retrieve para personalizar la respuesta al obtener un cliente por su pk.
        """
        try:
            cliente = Cliente.objects.get(pk=pk)
            serializer = ClienteSerializer(cliente)
            return Response(serializer.data, status=status.HTTP_200_OK)
        except Cliente.DoesNotExist:
            return Response({"error": "Cliente no encontrado"}, status=status.HTTP_404_NOT_FOUND)


class ReservaViewSet(viewsets.ModelViewSet):
    queryset = Reserva.objects.all()
    serializer_class = ReservaSerializer

class HistorialViewSet(viewsets.ModelViewSet):
    queryset = Historial.objects.all()
    serializer_class = HistorialSerializer

```from rest\_framework import viewsetsfrom rest\_framework.response import Responsefrom rest\_framework import statusfrom .models import Cliente, Reserva, Historialfrom .serializers import ClienteSerializer, ReservaSerializer, HistorialSerializer
class ClienteViewSet(viewsets.ModelViewSet):    queryset = Cliente.objects.all()    serializer\_class = ClienteSerializer
    def retrieve(self, request, pk=None):        """        Sobrescribe el método retrieve para personalizar la respuesta al obtener un cliente por su pk.        """        try:            cliente = Cliente.objects.get(pk=pk)            serializer = ClienteSerializer(cliente)            return Response(serializer.data, status=status.HTTP\_200\_OK)        except Cliente.DoesNotExist:            return Response({"error": "Cliente no encontrado"}, status=status.HTTP\_404\_NOT\_FOUND)

class ReservaViewSet(viewsets.ModelViewSet):    queryset = Reserva.objects.all()    serializer\_class = ReservaSerializer
class HistorialViewSet(viewsets.ModelViewSet):    queryset = Historial.objects.all()    serializer\_class = HistorialSerializer

Fundamentos de Django Rest Framework

Django REST Framework para APIs escalables

Qué es una API REST y cómo usar JSON

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 personalizadas en ViewSets REST

Autenticación y permisos en Django Rest Framework

Validaciones custom en Django Rest Framework

Serializadores Avanzados

Serializadores anidados en Django REST Framework

Calcular campos dinámicos con SerializerMethodField

Endpoint anidado para citas en Django REST

Testing y Desempeño

Tests de API con APIClient en Django

Throttling en Django Rest para evitar ataques DOS

Vistas genéricas en Django Rest Framework

Progreso del curso

Fundamentos de Django Rest Framework

Vistas y Endpoints

Serializadores Avanzados

Testing y Desempeño

Recursos

Recursos