Ahora que tenemos las rutas y ViewSets armados, vamos a entender el flujo de la API.

El flujo

Un usuario cualquiera debería poder entrar a un sitio, una app mobile o incluso una aplicación desktop, y elegir un color de una lista.

Para facilitar el asunto, vamos a asumir que siempre sea el usuario admin, el primero que tenemos en nuestra BD.

Esta elección de colores implica un GET a /api/colors.

Luego ese usuario debe seleccionar un color y emitir su voto. Aquí ocurren dos cosas: En principio, debemos hacer un GET a /api/votes/1 para validar que este voto ya exista. En caso negativo, vamos a permitirle votar; y en caso positivo, solo vamos a permitir que pueda ver los resultados de las votaciones, que por cierto es un GET a api/votes.

Si le permitimos votar, al apretar el botón será un POST a api/votes con un JSON que contendrá el contenido de un voto:

{
  "user": 1,
  "color": 1
}

Por supuesto, user y color tienen una clave foreanea a User y Color, por lo cual tenemos que pasarles el identificador, osea el ID de cada entidad.

Si no conoces DRF, es probable que pienses que estos métodos hay que armarlos. Nada más alejado de la realidad: como definimos los ViewSet y los asociamos al route, tenemos los siguientes endpoints pre-creados:

• GET api/votes: obtiene todos los votos.
• GET api/votes/: obtiene un voto según el id.
• POST api/votes/: crea un voto.
• PUT/PATCH api/votes/: modifica un voto entero o parcialmente.
• DELETE api/votes/: elimina un voto según el id.

Los mismos métodos tenemos para los colores, pero con "api/colors".

En una API más sencilla, mi trabajo habría terminado: ya tengo votos que se pueden emitir en base a colores, fin del asunto.

El problema radica en que tenemos algunos fallos en el flujo actual:

• No podemos buscar quien emitió el voto, porque "GET api/votes/" busca por el id del voto, no por el id del user.
• Se puede votar en nombre de cualquier usuario, porque "POST api/votes/" nos permite enviar el user que queramos.
• Se puede editar o borrar cualquier voto, por las mismas razones de arriba.
• Podemos borrar todos los colores y romper los votos. Como tenemos un CASCADE, si elimino el Azul por ejemplo, y habían 50 entradas de votos, se van a eliminar. Un problema serio.

Las soluciones

Por suerte, los ViewSets nos permiten modificar los comportamientos que vienen por defecto, pensemos que estamos trabajando con herencia y polimorfismo a la hora de heredar de ModelViewSet.

Hay que pararse en el medio y condicionar estos endpoints, pero previamente hay que armar un sistema de autenticación por tokens para crear una sesión y notificarle a la API con quién esta hablando.

Y eso lo veremos, querid@s amig@s, en el próximo artículo.