Los viewsets y los routers en Django Rest Framework permiten refactorizar endpoints de forma limpia, centralizar la lógica por recurso y generar URLs automáticamente. Con un solo ModelViewSet por entidad y un DefaultRouter, es posible reemplazar vistas separadas tipo list y detail de APIView por una solución más simple, legible y fácil de mantener.
¿Qué son los viewsets y por qué simplifican las vistas en Django Rest?
Un viewset es una clase reutilizable que agrupa el comportamiento de un recurso. En lugar de definir varias vistas para listar y detallar, un soloviewset concentra operaciones como crear, listar, modificar y actualizar el recurso. Con un router, se registran los viewsets y se generan los patrones de URLs de forma automática.
Menos código y más claridad: una clase por recurso.
Generación automática de URLs con nombres útiles para el código.
Soporte y mantenimiento más simple y estructurado.
Antes de implementarlo, conviene conocer la clase que se reutiliza. En el caso de ModelViewSet, los parámetros clave son: un QuerySet y un serializer. Estos dos son los requeridos para que el viewset funcione con el modelo correspondiente.
¿Cómo refactorizar a un ModelViewSet y conectar un router?
En la app “Doctors”, se crea un archivo dedicado (por ejemplo, viewsets.py) para centralizar los viewsets y mantener las vistas tradicionales por separado en views.py.
Definir el viewset del recurso Doctor.
# doctors/viewsets.pyfrom rest_framework.viewsets import ModelViewSet
from doctors.models import Doctor
from doctors.serializers import DoctorSerializer
classDoctorViewSet(ModelViewSet): queryset = Doctor.objects.all() serializer_class = DoctorSerializer
QuerySet: datos del modelo que gestionará el viewset.
Serializer: clase que serializa/deserializa el recurso.
Registrar el viewset en un router y exponer las URLs.
# config/urls.py (o el módulo de URLs principal)from rest_framework.routers import DefaultRouter
from doctors.viewsets import DoctorViewSet
router = DefaultRouter()router.register('doctors', DoctorViewSet)urlpatterns = router.urls
DefaultRouter: router que autogenera rutas y nombres.
register: vincula el prefijo 'doctors' con el DoctorViewSet.
router.urls: lista final de patrones de URL del proyecto.
Este patrón sustituye la definición manual de rutas individuales de list y detail. A medida que migres recursos, solo debes llamar a router.register(...) por cada uno.
¿Cómo verificar las URLs generadas y probar el recurso?
Es útil inspeccionar lo que produce el router antes de ejecutar el servidor. En una consola de Python con manage.py shell, puedes imprimir router.urls para ver una lista de patrones y sus nombres (por ejemplo, entradas tipo “doctors” y nombres como “doctor list”), lo que luego facilita el acceso programático desde el código.
Pasos de verificación y prueba rápida:
Abrir la terminal y ejecutar manage.py shell para revisar router.urls.
Iniciar el servidor con manage.py runserver.
Navegar a la API en localhost:8000/doctors y comprobar que carga.
Enviar un POST para crear un registro de Doctor: nombre, profesión, teléfono, correo, dirección y biografía.
Recargar para ver la lista de doctores con el nuevo registro.
Beneficios prácticos al usar viewsets y routers:
URLs consistentes con nombres útiles para el código.
Menos duplicación entre list y detail.
Refactor ordenado: migrar vistas a viewsets y registrarlas en el router permite un mantenimiento más claro a futuro.
Como ejercicio, migra todas las vistas existentes a viewsets, regístralas con el router y verifica que el proyecto siga funcionando como hasta ahora.
¿Con qué recurso te gustaría empezar a refactorizar usando viewsets y routers? Comparte dudas o avances en los comentarios.
{"first_name":"Fernando","last_name":"Martinez","qualification":"Profesional","contact_number":"1234567","email":"example@example.com","address":"123 Main St, Montevideo","biography":"Fernando is a professional doctor with years of experience in cardiology."}
thanks
En hora buena, Gracias :)
Y la abstracción continua…..
si que si 😁
Vamos paso a paso entendiendo cada abstracción, ideal para momentos donde las cosas no funcionan, esperamos saber cómo funcionan las herramientas por dentro.
Joderrrr esto es demasiado para alguien que viene de crear apis robustas con node JS, es demasiada abstracción 🥰
Cuéntanos un poco más de cómo lo hacías, Éstas experiencias son enriquecedoras
ufff esto.esta muy bueno!!! nunca había escuchado de los ViewSet
No conocia sobre esto, esta muy interesante
la documentacion tambien se aplica en swagger si se hace de esta forma
¿Al usar viewsets, que pasa entonces con la lógica de views (doctors)? ya que el CRUD alli se repite, se puede eliminar?
Básicamente, sí, los viewsets permiten eso, abstraer todo lo que en las vistas es más a un solo ViewSet que es mucho más pequeño y organizado
Un view set en Django Rest Framework es una clase que agrupa la lógica de varias vistas relacionadas en una sola unidad. En lugar de definir métodos HTTP individuales como GET o POST, un view set proporciona acciones como listar, crear, actualizar y eliminar, simplificando la gestión de las operaciones CRUD en una API. Esto no solo reduce la duplicación de código, sino que también mejora la organización y mantenibilidad del proyecto.
Tengan en cuenta que una vez hecho el Viewset la lógica dentro del archivo Views.py pasa a ser prácticamente innecesaria, los viewset abstrae esa lógica en módulos mas pequeños y fácil de trabajar
Pero sus métodos se pueden sobrescribir para modificar su lógica extendiendo su funcionalidad.
Creería que solo para el CRUD básico, y bueno, verificando que un user tenga permisos para hacer esa accion. Pero para un endpoint más complejo no creo que se pueda poner en un viewset, por decir, una ruta en donde se ve informe de cómo va la cartera de un negocio en detalle, eso sería correcto dejarlo en una view de la familia de las APIView.
Vengo de trabajar con laravel y este nivel de abstracción es bastante util, para no estar escribiendo codigo innecesario, para tablas catalogo y procesos no complejos ayuda un bastante