Antes de entrar de lleno al desarrollo del Cuadro de Mando Integral reimaginado usando AngularJS y Django, debemos comprender algunos conceptos torales del paradigma usado.

En la definición del paradigma REST, uno de sus principios fundamentales es que las operaciones deben ser sin estado.

Esto quiere decir que el servidor no debe guardar información del cliente. Sin embargo, este es el funcionamiento normal de Django y está activado cuando creamos un proyecto por medio de las sesiones. Las sesiones son muy fáciles de usar, porque podemos delegar a Django operaciones como el ingreso (login) y la salida (logout). El middleware django.contrib.sessions.middleware.SessionMiddleware se encarga de almacenar en la base de datos¹ la información sobre la sesión, de modo que siempre este disponible en el objeto request.

Sin estado

Como decía al principio, un sistema REST² no debe almacenar el estado de las sesiones. Esta es una restricción y en inglés se llama stateless.

De acuerdo al inventor de este paradigma de desarrollo, Roy T. Fielding la restricción stateless se define de la siguiente manera:

5.1.3 sin estado

[…] Cada solicitud desde el cliente al servidor debe contener toda la información necesaria para comprender dicha solicitud, y no puede tomar ventaja de cualquier contexto almacenado en el servidor. Por lo tanto, el estado de sesión se mantiene por completo en el cliente. […] De modo que, el servidor no tiene que almacenar cualquier estado de la sesión y, en consecuencia, no debe emitir identificadores de sesión.³

Acreditación y Autorización

Si necesitamos acceder a los recursos protegidos de nuestra API que requieran acreditación⁴, cada solicitud debe contener los datos necesarios para poder acreditar adecuadamente nuestra autorización para acceder a esos recursos. Y estos datos se envían en cada solicitud en el encabezado Authorization⁵ de HTTP.

Si tiene acceso a los recursos protegidos que requieren autenticación, cada solicitud debe contener todos los datos necesarios para ser autenticados adecuadamente / autorizado. Y datos de autenticación deben pertenecer al encabezado de autorización HTTP estándar. A partir de la RFC 7235:

Y ya que no podemos acreditar nuestra autorización para consultar los recursos protegidos usando sesiones como lo hacemos normalmente en Django, debemos usar otros métodos. Para efectos didácticos, usaremos Tokens, pero de eso hablaremos en el siguiente artículo de esta serie.