Cada petición lleva el contexto necesario y el servidor no mantiene estado entre llamadas.
Python · API REST · Email · Angular
Implementación de una API REST en Python para enviar email
Este artículo explica la parte de backend de un flujo habitual en aplicaciones web: construir una API REST, protegerla con token y consumirla después desde un cliente Angular.
La intención no es solo enseñar el endpoint final, sino ordenar la arquitectura, justificar por qué REST encaja bien en este escenario y mostrar una implementación realista basada en Python.
Vídeo complementario
Si prefieres revisar la explicación apoyándote en una demostración guiada, puedes abrir el vídeo asociado al artículo.
https://www.youtube.com/watch?v=RSGQuH_gWNw
En el vídeo se sigue la misma idea del artículo: entender qué papel cumple la API, cómo se estructura el backend y cómo termina consumiéndose desde el cliente Angular.
1. Qué es una API REST
La mayoría de aplicaciones web o móviles necesitan comunicarse con un servidor para leer, enviar o transformar datos. En proyectos modernos, esa comunicación suele resolverse con HTTP o HTTPS y con una API orientada a recursos.
REST destaca por ser un enfoque sencillo, bien entendido y muy adecuado para escalar servicios donde varios clientes consumen el mismo backend: web, móvil, automatizaciones internas o terceros.
Si es la primera vez que te acercas a este tipo de arquitectura, conviene recordar que hoy en día la mayoría de servicios que utilizamos a diario funcionan con algún tipo de API. Redes sociales, plataformas de vídeo, sistemas de autenticación o aplicaciones móviles dependen de este modelo para crecer y comunicarse.
Respecto a la etimología, REST significa Representational State Transfer. En la práctica, nos sirve para describir interfaces donde los clientes acceden a recursos a través de HTTP y reciben representaciones de esos datos en formatos como JSON o XML.
Otro punto importante es que un servicio REST no mantiene estado entre peticiones. Eso significa que el servidor no recuerda automáticamente al cliente entre llamada y llamada: si hace falta autenticación, contexto o permisos, el cliente debe aportar esa información cada vez.
Puede parecer una desventaja porque obliga a reenviar credenciales o tokens, pero en realidad aporta una ventaja enorme: la escalabilidad. Si el servidor no tiene que conservar estado en memoria para cada usuario, resulta mucho más sencillo crecer en horizontal y soportar más carga.
La API se diseña alrededor de URIs y verbos HTTP en lugar de métodos RPC opacos.
La ausencia de estado en memoria simplifica el crecimiento horizontal del servicio.
Un mismo backend puede ser consumido desde Angular, scripts Python o herramientas como Postman.
Que una API sea stateless obliga a enviar credenciales o tokens en cada petición, pero a cambio reduce complejidad de sesión y facilita la escalabilidad del sistema.
2. SOAP vs REST
SOAP sigue siendo válido en ciertos entornos empresariales, pero su complejidad suele ser innecesaria para APIs web orientadas a frontend, automatizaciones sencillas o servicios ligeros.
En este proyecto interesa un modelo más directo: recursos, JSON, autenticación simple y facilidad de consumo desde Angular.
SOAP está pensado para cubrir necesidades más amplias y formales, incluyendo escenarios complejos de seguridad, transaccionalidad o mensajería. Eso puede ser adecuado en ciertos entornos empresariales, pero también añade una complejidad que muchas aplicaciones web no necesitan.
Otra diferencia importante es la orientación del modelo. SOAP suele estar más cerca de invocar métodos remotos, mientras que REST se centra en recursos accesibles por URI. En lugar de pensar en “llamar a una función remota”, pensamos en “operar sobre un recurso” usando GET, POST, PUT o DELETE.
Por ejemplo, en un servicio más clásico podríamos imaginar un método `GetAll()` o `GetById()`. En REST, en cambio, el foco está en rutas como `/plates` o `/plates/123`, y es el verbo HTTP el que indica si estamos consultando, creando, modificando o eliminando información.
3. Implementación en Python
En esta guía se utiliza Python porque permite construir microservicios con rapidez, leer el código con facilidad y aprovechar una enorme base de librerías y ejemplos disponibles.
El lenguaje elegido no necesita ser el más rápido a bajo nivel, porque aquí la API no es un componente que requiera exprimir al máximo el rendimiento bruto. Lo que interesa es avanzar rápido, mantener el código legible y poder apoyarse en herramientas muy maduras.
En ese contexto, Python encaja especialmente bien: es un lenguaje muy extendido, con sintaxis clara, múltiples paradigmas de programación y una enorme disponibilidad de librerías y ejemplos reales.
Instalación inicial
Este primer bloque cubre la preparación mínima del entorno. Clonar el repositorio y cargar dependencias es el paso previo para poder ejecutar la API, revisar el código y hacer pruebas locales.
Estructura del proyecto
Antes de entrar en los endpoints concretos, conviene ver cómo está dividido el proyecto. Esta estructura ayuda a separar configuración, autenticación, utilidades y recursos de la API.
La estructura separa claramente recursos de API, login, configuración y utilidades. Esa división es pequeña, pero suficiente para que el proyecto pueda crecer sin convertirse en un único fichero difícil de mantener.
3.1 Recursos publicados
Toda API REST se basa en exponer recursos mediante rutas bien definidas. En este ejemplo se publican endpoints para obtener token, validarlo y enviar emails protegidos.
Listado de recursos
Este fragmento centraliza las rutas disponibles. Es importante porque muestra de un vistazo qué recursos expone la API y qué clase resuelve cada endpoint.
Cuando la aplicación empieza a crecer, tener bien identificadas las rutas y su correspondencia con cada recurso evita mucha confusión y facilita que otros desarrolladores entiendan la API sin recorrer todo el proyecto.
Envío simple de email
Aquí ya aparece la lógica funcional del proyecto: un recurso que recibe el email destino, delega el trabajo en una clase de envío y devuelve una respuesta JSON sencilla confirmando el resultado.
Lo importante no es solo mandar el correo, sino separar bien la responsabilidad del endpoint respecto a la clase que realmente ejecuta la operación técnica.
Este desacoplamiento es útil porque el recurso HTTP queda centrado en recibir parámetros y construir la respuesta, mientras que la clase auxiliar puede evolucionar por separado si cambia el proveedor de correo, la librería o la estrategia de envío.
En este ejemplo se ha utilizado una cuenta de Gmail para simplificar el flujo y mostrar de forma directa cómo una API puede encapsular una operación útil para otros clientes.
3.2 Seguridad y autenticación
Para restringir el acceso al endpoint de envío se utiliza un token. El cliente primero obtiene credenciales válidas y luego adjunta ese token en las peticiones protegidas.
En este punto aparece una duda natural: si la API expone un recurso que envía correos, ¿cómo evitamos que cualquier tercero lo invoque libremente? La respuesta es proteger el acceso mediante un token asociado a un proceso previo de autenticación.
En el proyecto original esto se resuelve haciendo que el recurso de envío herede de una clase segura encargada de validar si la petición lleva un token autorizado.
Endpoint de login
Este endpoint recibe las credenciales del cliente y devuelve un token si son correctas. Es la puerta de entrada al resto de recursos protegidos de la API.
Validación del usuario
En este bloque se ve la lógica que decide si el usuario puede autenticarse. Aunque el ejemplo es simple, sirve para entender dónde estaría la comprobación de credenciales en un proyecto real.
En la aplicación original esta lógica vive dentro de la carpeta `login`, donde se resuelve qué usuario puede entrar y qué información se incorpora al token de acceso.
Petición para obtener el token
Una vez visto el servidor, este ejemplo enseña cómo sería la llamada desde el cliente o desde una herramienta de pruebas. El objetivo es dejar claro qué URL, cabeceras y payload necesita la autenticación.
Este tipo de ejemplo es especialmente útil cuando empiezas a probar la API con Postman o cuando otro cliente, como Angular, necesita reproducir exactamente el mismo contrato HTTP.
Petición para enviar el correo
Este segundo ejemplo representa el uso real del recurso protegido: se adjunta el token en la cabecera y se invoca el endpoint que realiza el envío del email.
En otras palabras, el flujo completo queda dividido en dos pasos: autenticarse y obtener token, y después reutilizar ese token para acceder al recurso que realiza la operación real de negocio.
4. Pruebas con Postman
Postman resulta útil para validar la API antes de integrarla en Angular. Permite revisar cabeceras, autenticación, payloads y respuestas sin depender todavía del frontend.
Postman no solo sirve para lanzar peticiones manuales. También ayuda a documentar el comportamiento de la API, compartir pruebas con otros miembros del equipo y comprobar rápidamente si un error viene del backend o del cliente.
El flujo normal de prueba sería: preparar las cabeceras, enviar usuario y contraseña para recuperar el token, y reutilizar ese token en la cabecera `Authorization` del recurso protegido.
En la práctica, Postman se convierte en una herramienta muy cómoda tanto para desarrolladores como para perfiles de operación o monitorización. Permite comprobar si la API responde correctamente antes de escribir una sola línea de frontend.
Alrededor de esa idea de prueba, la plataforma también añade utilidades para documentar colecciones, organizar equipos, compartir peticiones y trabajar con un enfoque más cercano a API First.
A día de hoy Postman dispone de aplicaciones para Windows, Linux y macOS, además de opciones colaborativas en la nube. Si necesitas instalarlo, puedes descargarlo desde postman.com/downloads.
Su uso básico es gratuito, aunque también existen planes más avanzados para equipos que necesitan más capacidad, funciones colaborativas adicionales o integración con sistemas corporativos.
Configurar cabeceras HTTP acordes al endpoint y al formato esperado por la API.
Enviar usuario y contraseña para recuperar el token de acceso.
Reutilizar ese token en la cabecera `Authorization` al invocar recursos protegidos.
Una vez validada la API, el frontend Angular solo tiene que consumir un contrato ya estable.
Ejemplo de ejecución
El primer paso consiste en conectarse con la API y preparar correctamente la petición HTTP. Eso implica ajustar cabeceras y formato para que el backend interprete la solicitud como una llamada REST válida.
El segundo paso consiste en enviar usuario y contraseña para recuperar el token. Esa respuesta confirma que el proceso de autenticación funciona correctamente y deja lista la credencial para el resto de llamadas.
Una vez obtenido el token, se incorpora a la cabecera de autorización y ya es posible invocar el recurso de envío de correo. Esa es la comprobación final de que autenticación y endpoint protegido están coordinados.
