Django REST framework

Django REST framework es el framework por excelencia si queremos crear una API RESTful en Django. Proporciona todo lo necesario para su implementación de una manera completa y eficaz. Lista de virtudes:

• Autenticación
• Validación de datos
• Excepciones en JSON
• Soporte para relaciones
• Paginación y filtros

Para instalarlo:

Respuestas

Antes de comenzar vamos a ver la implementación de los dos tipos de respuesta comunes que una API suele ofrecer:

1. Repsuesta JSON:

Por defecto, y por seguridad, JsonResponse sólo permite el uso de diccionarios. Si queremos devolver otra cosa podemos saltarnos esta seguridad incluyendo el parametro safe a False.

2. Repsuesta HTTP:

Generalmente usado como respuestas vacias con códigos de estado HTTP. Por ejemplo, el código 204 significa No Content. Esto indica que la petición fue aceptada pero que no se devuelve datos. Usamos esta tipo de respuesta cuando un recurso es actualizado (PUT) o borrado (DELETE).

El otro código más popular es 201, que significa Created. Y lo utilizamos cuando un recurso es creado (POST). En la respuesta también incluiremos la URL para poder acceder al objeto recien creado.

Serializadores:

La parte más importante. Cómo pasamos los datos de un formulario a nuestra API y viceversa. Y DRF (Django Rest Framework) usa la clase Serializer para hacer la conversion en ambas direcciones de una forma totalmente desacoplada. Y como no, podemos crear nuestro serializers a partir de nuestro Modelo, para no tener que crear objetos de nuestro modelo. Se hace a través de la clase ModelSerializer:

El ModelSerializer ya implementa los métodos create y update. Ejemplo:

Otra cosa interesante que podemos hacer es sobre-escribir o añadir campos:

Lo último que queda por contar del ModelSerializer es como marcar argumentos de solo lectura:

Validaciones

Existen tres tipos de validaciones:

• A nivel de campo.
• A nivel de objeto.
• A nivel de function.

Validación a nivel de campo

Son los que tienen la forma validate_{campo}() por ejemplo validate_email() este método es similar al método de Django forms clean_{campo}(). Ejemplo:

Validación a nivel de objeto

Si necesitamos validar dos campos entre ellos, este es el modelo a seguir. Y se realiza añadiendo el método validate() al serializer.

Validación a nivel de Función

Esta validación es útil cuando tenemos un valor con el que validar, un argumento. Útil cuando queremos aplicar la misma validación a varios campos. Ejemplo: si queremos asegurarnos de que los nombres y apellidos empiezan en mayúsculas.

Las vistas

Ya sólo nos quedan las vistas, y su routing por supuesto. DRF proporciona varias maneras de crearlas:

rest_framework.decorators.api_view

Decorator para marcar funciones de views como métodos del API. El decorator es rest_framework.decorators.api_view y nos permite cosas como:

• Devolver error automáticamente si el método no estás soportado.
• Parsear los datos del request.
• Maneja el response y es capaz de devolver diferentes tipos de respuesta dependiendo del cliente.

Ejemplo:

El decorator también incluye data en el request, que podemos usar en nuestros métodos, como por ejemplo para actualizar un estudiante:

Así que no es necesario deserializar json por nuestra cuenta. Por último no necesitamos usar JsonResponse. Utilizarmos Response.

El decorator hace que la respuesta sea diferente si se pide desde un navegador a si se pide por postman. En postman o ajax devuelve un ajax, en el navegador muestra una web con la llamada y el resultado, y opciones para probar.

Ejemplo completo:

api_urls.py

APIView

La clase rest_framework.views.APIView es una clase base de la que puedes heredar para definir las vistas de la API como class-based views. Su uso no ofrece muchas ventajas con respecto a las vistas de función que hemos visto justo arriba, pero es posible que quieras utilizarla si prefieres las class-based views. Veremos dónde las vistas basadas en clases tienen verdaderas ventajas en la siguiente sub-sección. Y asi es como luce:

Pero el verdadero cambio viene con las vistas genéricas de DRF, donde el código queda en la mínima expresión.

Generic Views y Mixins

DRF usa el patron mixin para añadir funcionalidad a las vistas genéricas. Esto no significa nada más que heredar de varias clases. Ejemplo:

Seguimos teniendo que definir los métodos get y post, pero sus cuerpos quedan reducidos a una sola línea. Pero estas clases se pueden incluso simplificar más!!!

Como estos mixins son utilizados conjuntamente muy a menudo, DRF proporciona una clase base generics.ListCreateAPIView que los combina para las vistas, y la clase base generics.RetrieveUpdateDestroyAPIView para el detalle. De esta manera reducimos más nuestra api. Que nos quedaría:

api_urls.py