Saltar a contenido

Visión general de las solicitudes HTTP#

iThome Ironman 2024

Este es el noveno artículo de la serie tutorial de Django Ninja.

¡Te damos la bienvenida a la Sección 2 del Capítulo 3!

Como la implementación de la lógica central de la API, las funciones view son, sin duda, el alma de la API de Django Ninja.

Al igual que FastAPI y Flask, Django Ninja adopta principalmente function-based views (en adelante, FBV). Por lo tanto, sus puntos clave de aprendizaje giran casi en su totalidad en torno al input y output de las funciones view.

En otras palabras, las capacidades de todo el marco Django Ninja constituyen estas partes clave de la función view, incluyendo pero no limitándose a:

  1. Manejar los parámetros y el body de las solicitudes HTTP.
  2. Manejar la serialización y formateo del contenido de la respuesta HTTP.
  3. Validación de datos y manejo de errores.

Juntas constituyen las funcionalidades principales de Django Ninja.

Esta sección y la siguiente se concentrarán en los dos primeros puntos mencionados anteriormente: solicitudes y respuestas. En cuanto al tercer punto, lo dejaremos para presentarlo en el Capítulo 5.

Proyecto de ejemplo en GitHub#

👉 Django-Ninja-Tutorial

Guía de esta sección#

Tras la sección anterior sobre «Enrutamiento», esta sección explorará cómo maneja Django Ninja las solicitudes HTTP: cómo analizar el path, los parámetros de consulta URL y el body.

Esta sección consta de 4 artículos en total:

Además, dado que las funciones view para procesar solicitudes ya involucran el uso de type hints por parte de Django Ninja para validar los datos de la solicitud, nuestro código de ejemplo comenzará a incluir pistas de tipo en Python.

La sintaxis de type hints tomará Python 3.12 como referencia.

Documentación oficial#

La redacción de esta serie consulta de vez en cuando la «Documentación oficial de Django Ninja», especialmente en la presentación de la arquitectura.

Sin embargo, después de todo la documentación está dirigida a todos los desarrolladores y no considera suficientemente el orden de aprendizaje.

Esta serie está dirigida principalmente a principiantes, por lo que nos enfocaremos más en la práctica real y en las necesidades de los principiantes, complementando con conocimientos previos cuando corresponda para asegurar que la curva de aprendizaje sea relativamente suave.

Además, respecto al propio marco de trabajo, también proporcionaremos más ejemplos y explicaciones para que los nuevos conceptos sean más fáciles de comprender y dominar.

De todos modos, la documentación oficial sigue siendo un recurso que deberás consultar constantemente al usar Django Ninja, ¡aunque esté escrita de forma bastante más «sencilla» comparada con la documentación de Django o Django REST framework!

Propósito de este artículo#

Como introducción general a la segunda sección, este artículo tiene como objetivo brindarte una comprensión básica de las funciones view en Django Ninja y cómo manejan las solicitudes HTTP.

Te iremos familiarizando con ello paso a paso a través de los siguientes tres puntos clave:

  1. Las ventajas de las FBV.
  2. El flujo de procesamiento de solicitudes HTTP en Django Ninja.
  3. La estrecha integración entre Django Ninja y Type Hints.

Sin más preámbulos, comencemos directamente.

Tanto las Class-based views (CBV) como las FBV son medios para implementar las Views dentro de la arquitectura MTV de Django, y cada una tiene sus escenarios de aplicación.

Las CBV cuentan con la ventaja de la reutilización de código, siendo adecuadas para proyectos grandes. Por su parte, las FBV destacan por ser simples y directas, lo que facilita el desarrollo rápido de proyectos pequeños y medianos.

Para una comparación entre ambas, puedes consultar este artículo «Day27 : CBV vs. FBV».

Dado que Django Ninja adopta las FBV, este artículo solo explorará las ventajas de las FBV.

1. Ventajas de las FBV#

Las FBV son la forma de view que adopta Django Ninja. Comparadas con las CBV, las FBV son más concisas y flexibles, lo que permite a los desarrolladores escribir la lógica de la API fácilmente sin necesidad de conocer demasiados antecedentes, como «cómo sobrescribir correctamente cierto atributo de una CBV».

Simplicidad y flexibilidad#

Las FBV no requieren heredar ni sobrescribir métodos de clase; toda la lógica se concentra en una sola función.

Esto hace que escribir y mantener el código sea mucho más intuitivo.

Como una FBV es esencialmente una función, puede aplicar de forma más flexible diversas lógicas y condiciones. Los desarrolladores pueden controlar por completo todo el flujo de procesamiento de la solicitud en una sola función, sin tener que considerar la estructura de clases ni las relaciones de herencia.

Fácil de depurar#

El código de las FBV es relativamente intuitivo y resulta más fácil de leer y comprender para los principiantes. Cuando ocurre un error, puedes localizar el problema rápidamente, una comodidad difícil de alcanzar con las CBV.

Mi perspectiva#

Django es un marco con funciones muy completas, pero a menudo se le critica por ser «pesado». Las FBV alivian hasta cierto punto esta sensación de pesadez.

Imagina a un principiante que acaba de entrar en contacto con Django: tras comprender la configuración del entorno del marco de trabajo, ¿no sería demasiado abrumador tener que adentrarse además en el mundo de las CBV?

En resumen, si me preguntas a mí, prefiero absolutamente las FBV; además, la «lógica ligera» es la tendencia del desarrollo moderno.

2. Flujo de procesamiento de solicitudes HTTP en Django Ninja#

El procesamiento de «solicitudes» en Django Ninja se puede dividir en varios pasos clave:

  1. Coincidencia de rutas: Cuando entra una solicitud, el marco primero compara la URL de origen con las reglas de ruta definidas (endpoints). Si la coincidencia es exitosa, pasa la solicitud HTTP y los parámetros relevantes a la función view.
  2. Análisis de parámetros: Extrae los parámetros de ruta (path parameters) y los parámetros de consulta (query parameters) de la URL, convirtiéndolos en los «argumentos» de la función view. Realiza automáticamente la conversión y validación de tipos según los type hints de la función.
  3. Procesamiento de Request body: Para solicitudes con body como POST o PUT, Django Ninja permite a los desarrolladores definir modelos de datos para el body usando Schema (BaseModel de Pydantic), y mapea automáticamente los datos entrantes hacia esos modelos.

Flujo de procesamiento de solicitudes HTTP en Django Ninja

El punto 1 anterior ya fue explicado en detalle en la primera sección de este capítulo.

Los puntos 2 y 3 son el contenido principal de los 4 artículos de esta sección.

3. La estrecha integración entre Django Ninja y Type Hints#

Django Ninja depende enormemente de los type hints de Python para manejar los datos en las solicitudes HTTP.

Y a través de Pydantic implementa la validación automática de datos y la conversión de tipos, reduciendo la carga del desarrollador de inspeccionar y convertir datos manualmente.

Por ejemplo, el siguiente código:

@router.get("/posts/{post_id}")
def get_post(request, post_id: int):
    return {"post_id": post_id}

Cuando el parámetro post_id se marca como int, Django Ninja realiza una comprobación de tipos. Si el parámetro ingresado no puede convertirse a int, el marco devolverá directamente una respuesta HTTP con código de estado 422.

En otras palabras, si marcas post_id como str, Django Ninja convertirá automáticamente post_id a una cadena de texto.

Recuerdo que cuando entré en contacto por primera vez con Django Ninja, me deslumbró bastante la capacidad de aprovechar los type hints de Python hasta ese nivel, haciendo que no sirvan únicamente para la seguridad de tipos, sino que se integren en todo el flujo de desarrollo de API.

El parámetro request en las funciones view#

En el ejemplo anterior hay un detalle digno de atención: el primer parámetro de la función view: request.

En Django, el primer parámetro de una función view debe ser request. El nombre de este parámetro se puede definir libremente, pero por lo general se nombra request.

Al recibir una solicitud HTTP, Django empaqueta toda la solicitud en un objeto HttpRequest y lo pasa como primer parámetro a la función view, por lo que es indispensable.

Artículo relacionado: Introducción a los atributos comunes de HttpRequest en Django

El parámetro request es sumamente importante en Django y Django REST framework, ya que se utiliza con frecuencia para obtener los parámetros de consulta de la solicitud, el body, entre otros contenidos.

En Django Ninja, estos datos se obtienen directamente a través de los parámetros de la función, por lo que aunque request sigue siendo indispensable, su frecuencia de uso es menor.

Siguientes pasos#

A continuación, profundizaremos en los detalles concretos sobre cómo maneja Django Ninja las solicitudes.

El próximo artículo se centrará en los parámetros de ruta (path parameters) y explorará cómo usarlos en combinación con los path converters nativos de Django. ¡No te lo pierdas!