🎓 Servicios Web

SOAP, REST, Django y Docker Explicados

📋 Índice de Contenidos

📡1. ¿Qué es SOAP y por qué existe aún?

Entendiendo SOAP de forma simple

SOAP (Simple Object Access Protocol) es un protocolo antiguo pero robusto para intercambiar información estructurada entre sistemas. Piensa en él como un mensajero muy formal y estricto.

📋 Características de SOAP

  • Usa XML (muy estructurado y verboso)
  • Tiene un "sobre" (Envelope) que envuelve todo
  • Requiere un contrato WSDL (descripción del servicio)
  • Es muy estricto con las reglas
  • Tiene seguridad integrada (WS-Security)

🚀 Por comparación: REST

  • Usa JSON (más ligero y simple)
  • No necesita "sobre", es directo
  • La documentación es opcional (OpenAPI)
  • Es flexible y adaptable
  • Seguridad vía HTTPS + tokens

Analogía del Mensajero

📮 SOAP: Carta Formal

Imagina que envías una carta formal al banco:

  1. Usas un sobre oficial (Envelope)
  2. Incluyes tu identificación (Header)
  3. Escribes el mensaje formal (Body)
  4. Lo envías por correo certificado

El banco DEBE responder en el mismo formato estricto.

💬 REST: Mensaje de WhatsApp

Imagina que envías un mensaje a un amigo:

  1. Escribes directo lo que necesitas
  2. Usas emojis si quieres 😊
  3. Puede ser corto o largo
  4. La respuesta es rápida

Tu amigo puede responder como quiera.

Ejemplo Real de SOAP

📋 Ejemplo: Solicitar información de un libro vía SOAP 
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
        <!-- Información de autenticación -->
        <authentication>
            <username>biblioteca_admin</username>
            <token>abc123xyz789</token>
        </authentication>
    </soap:Header>
    
    <soap:Body>
        <!-- Petición: obtener libro por ID -->
        <getLibro>
            <libroId>5</libroId>
        </getLibro>
    </soap:Body>
</soap:Envelope>
📬 Respuesta del servidor SOAP 
<?xml version="1.0"?>
<soap:Envelope>
    <soap:Body>
        <getLibroResponse>
            <libro>
                <id>5</id>
                <titulo>El Quijote</titulo>
                <autor>Miguel de Cervantes</autor>
                <isbn>978-8424117524</isbn>
                <disponible>true</disponible>
            </libro>
        </getLibroResponse>
    </soap:Body>
</soap:Envelope>

💡 Interpretación del mensaje SOAP:

"Estimado Sistema Receptor: Le adjunto en este sobre formal mi petición. Me identifico con el usuario 'biblioteca_admin' y token 'abc123xyz789'. Solicito cortésmente la información del objeto Libro, que contiene el título 'El Quijote' y el identificador numérico '5'. Atentamente, Sistema Emisor".

¿Por qué existe aún? (Casos de Uso)

Si estás haciendo tu biblioteca desde cero hoy, probablemente NO usarás SOAP para tu propia API. Pero podrías tener que usarlo si tu biblioteca necesita conectarse con terceros:

🏦

Sistemas Bancarios/Pagos

Muchos bancos antiguos usan SOAP por sus estándares de seguridad (WS-Security) y transacciones atómicas (ACID).

🏛️

Gobierno y Hacienda

Si tu biblioteca tiene que reportar impuestos o facturas a un sistema gubernamental, es muy probable que ese sistema estatal (hecho hace 15 años) solo acepte SOAP.

💾

Sistemas Legacy (Heredados)

Si tu biblioteca universitaria debe conectarse a una base de datos central creada en el 2005 ("Mainframe"), esa conexión será vía SOAP.

🏥

Sector Salud

Hospitales y sistemas de salud usan SOAP para intercambiar historiales médicos (estándar HL7) de manera segura y auditada.

📚2. Ejemplo en tu Sistema de Biblioteca

Imagina este escenario real:

1Tu App Móvil (REST)

El alumno usa la App para reservar un libro. La App habla con tu Django usando REST (JSON). Es rápido y ligero.

Solicitud REST desde la App 
POST /api/reservas/ HTTP/1.1
Content-Type: application/json

{
    "libro_id": 5,
    "usuario_id": 123,
    "fecha_reserva": "2026-02-02"
}

2El Cobro de Multas (SOAP)

El alumno debe una multa. Tu sistema Django necesita reportar esa deuda al sistema financiero central de la Universidad para bloquear su matrícula.

  • El sistema financiero es viejo y estricto.
  • Tu Django tendrá que armar un paquete SOAP (XML) y enviarlo al servidor de la universidad.
  • El servidor de la universidad responde con otro XML confirmando la recepción.
Solicitud SOAP al Sistema Universitario 
<soap:Envelope>
    <soap:Body>
        <reportarMulta>
            <alumnoId>123</alumnoId>
            <monto>50.00</monto>
            <concepto>Retraso devolución libro</concepto>
            <fecha>2026-02-02</fecha>
        </reportarMulta>
    </soap:Body>
</soap:Envelope>

Flujo Completo del Sistema

📱 App Móvil
(Usuario Final)
Usa REST/JSON
→
🐍 Django Backend
(Tu Sistema)
Maneja ambos
↓
🏛️ Sistema Universitario
(Legacy System)
Solo acepta SOAP/XML

⚔️3. REST vs SOAP: Comparación Detallada

Tabla Comparativa Completa

Característica REST (Lo que usas ahora) SOAP (Lo "corporativo")
Formato JSON (generalmente), también XML, HTML, texto XML (siempre, no hay opciones)
Filosofía Flexible, fácil de leer, adaptable Estricto, basado en reglas rígidas
Peso Ligero (gasta pocos datos, ideal móviles) Pesado (mucho texto extra, verbose)
Definición Documentación (OpenAPI/Swagger) opcional Contrato estricto (WSDL) obligatorio
Uso común Apps móviles, Web modernas, APIs públicas Bancos, Gobierno, Enterprise, B2B
Velocidad ⭐⭐⭐⭐⭐ Rápido ⭐⭐⭐ Más lento
Curva de aprendizaje ⭐⭐⭐⭐⭐ Fácil ⭐⭐ Complejo
Seguridad HTTPS + tokens (OAuth2, JWT) WS-Security integrado
Estado Stateless (sin estado entre peticiones) Puede mantener estado (stateful)
Transacciones Hay que implementarlas manualmente ACID nativo (todo o nada)
Caché ✅ Excelente soporte HTTP ❌ No soporta caché
Verbos HTTP GET, POST, PUT, DELETE, PATCH Solo POST (todo por XML)
Popularidad 2026 📈 85% del mercado 📉 15% (sistemas legacy)
Ejemplo típico Instagram, Twitter, GitHub API SWIFT (transferencias bancarias)

Comparación Visual: Mismo Request

🚀 REST Request

GET /api/libro/5 HTTP/1.1
Host: biblioteca.com
Authorization: Bearer abc123
Accept: application/json

Tamaño: ~80 bytes

Tiempo: ~50ms

Legibilidad: ⭐⭐⭐⭐⭐

📋 SOAP Request

<soap:Envelope...>
  <soap:Header>
    <auth>abc123</auth>
  </soap:Header>
  <soap:Body>
    <getLibro>
      <id>5</id>
    </getLibro>
  </soap:Body>
</soap:Envelope>

Tamaño: ~300 bytes

Tiempo: ~150ms

Legibilidad: ⭐⭐⭐

🔒4. Seguridad: ¿SOAP es más "autenticado"?

Respuesta directa:

Tu intuición no está mal encaminada, pero la palabra correcta no es "más autentificado", sino más estandarizado en seguridad.

🛡️ SOAP (WS-Security)

Tiene estándares de seguridad integrados en su propia estructura (llamado WS-Security).

Capacidades de seguridad:

  • ✅ Cifrar el mensaje completo o solo partes de él
  • ✅ Firmas digitales estrictas para garantizar identidad
  • ✅ Es muy difícil de alterar sin romper el protocolo
  • ✅ Autenticación a nivel de mensaje (no solo transporte)
  • ✅ Certificados X.509 integrados
  • ✅ Timestamps y expiración de mensajes

🏦 Por eso los bancos y gobiernos lo aman:

Es muy difícil de hackear porque la seguridad viene "de fábrica". No depende de que el programador la implemente correctamente.

🔐 REST (Seguridad por Transporte)

Depende de la seguridad del transporte (HTTPS/TLS). Para autenticación usa tokens.

Métodos de autenticación REST:

  • JWT (JSON Web Tokens) - El más popular
  • OAuth2 - Usado por Google, Facebook, GitHub
  • API Keys - Simple pero menos seguro
  • Basic Auth - Usuario y contraseña (solo con HTTPS)
  • Bearer Tokens - Tokens de acceso

💡 Veredicto:

Es igual de seguro para el 99% de las aplicaciones modernas, pero la seguridad se implementa "por encima" (HTTPS), no viene "dentro" del mensaje como en SOAP.

Comparación de Seguridad

Aspecto de Seguridad SOAP REST
Cifrado WS-Security (cifrado de mensaje completo o parcial) HTTPS/TLS (cifrado de transporte)
Autenticación WS-Security, certificados X.509, SAML JWT, OAuth2, API Keys, Basic Auth
Firma Digital ✅ Integrada (XML Signature) ⚠️ Opcional (hay que implementarla)
Integridad del Mensaje ✅ Garantizada por diseño ✅ Con HTTPS correctamente configurado
No Repudio ✅ Soporte nativo ⚠️ Hay que implementar
Auditoría ✅ Cada mensaje es trazable ⚠️ Depende de logs del servidor
Nivel de Seguridad ⭐⭐⭐⭐⭐ Máximo (nivel empresarial) ⭐⭐⭐⭐ Alto (suficiente para mayoría)
Complejidad de Implementación ⭐⭐ Alta ⭐⭐⭐⭐⭐ Baja

En resumen: SOAP tiene seguridad de nivel empresarial "de fábrica". REST es seguro, pero depende de cómo tú configures el servidor y el HTTPS.

🎯5. ¿Cuál te "genera mejor"? (¿Cuál deberías usar?)

No hay uno mejor que el otro en absoluto, depende de qué estás construyendo

🌳 Árbol de Decisión Interactivo

Responde estas preguntas para saber qué usar:

❓ ¿Tu aplicación es para usuarios finales (app móvil o web)?

SÍ → Usa REST ✅

Las apps modernas necesitan velocidad, bajo consumo de datos, y facilidad de uso

❓ ¿Estás conectando con sistemas bancarios, financieros o gubernamentales?

SÍ → Usa SOAP ⚠️ (o lo que ellos requieran)

Estos sectores tienen estándares establecidos con SOAP desde hace décadas

❓ ¿Necesitas transacciones ACID garantizadas al 100%?

SÍ → SOAP es mejor 🔒

ACID = Atomicidad, Consistencia, Aislamiento, Durabilidad

❓ ¿Quieres que otros desarrolladores usen tu API fácilmente?

SÍ → Usa REST 🚀

REST es mucho más fácil de aprender, documentar y usar

❓ ¿Estás creando microservicios internos de tu empresa?

SÍ → Usa REST 💡

Los microservicios modernos funcionan mejor con REST por su ligereza

🚀 Usa REST si:

  • ✅ Estás creando una app móvil o página web moderna (SPA)
  • ✅ Necesitas velocidad y que la aplicación cargue rápido
  • ✅ Quieres que otros desarrolladores se conecten fácilmente a tu API
  • ✅ Estás trabajando con Microservicios
  • ✅ Tu equipo está aprendiendo desarrollo web
  • ✅ Necesitas escalabilidad horizontal (muchos usuarios simultáneos)
  • ✅ Trabajas con tecnologías modernas (Node.js, Python, Ruby, Go)
  • ✅ Quieres aprovechar el caché HTTP
  • ✅ Necesitas soporte para múltiples formatos (JSON, XML, CSV)

🏛️ Mantén o usa SOAP si:

  • ⚠️ Estás conectando con sistemas bancarios, financieros o gubernamentales antiguos
  • ⚠️ Necesitas transacciones ACID garantizadas
  • ⚠️ Ejemplo: Si falla el pago, se debe cancelar el envío y devolver dinero automáticamente
  • ⚠️ Necesitas un contrato formal estricto (WSDL)
  • ⚠️ Trabajas con sistemas legacy (antiguos) que solo soportan SOAP
  • ⚠️ Necesitas seguridad de nivel empresarial integrada (WS-Security)
  • ⚠️ Requieres mensajería asíncrona confiable con garantía de entrega
  • ⚠️ El cliente/socio comercial exige SOAP por política
  • ⚠️ Necesitas auditoría completa de cada transacción

🌍6. Casos de Uso Reales

Ejemplos del Mundo Real

SOAP en Acción

🏦 Caso 1: Transferencia Internacional (SWIFT)

Contexto: Transferir $10,000 USD de México a España

Por qué SOAP:

  • Necesita garantía de transacción (ACID)
  • Si falla, debe revertirse automáticamente
  • Requiere auditoría completa y trazabilidad
  • Firmas digitales obligatorias
  • Estándar internacional establecido

Resultado: SOAP es la única opción viable

🏛️ Caso 2: Facturación Electrónica SAT (México)

Contexto: Enviar facturas al sistema del SAT

Por qué SOAP:

  • Regulación gubernamental estricta
  • Sistema legacy desde 2004
  • WSDL definido por el gobierno
  • Certificados digitales SAT obligatorios
  • No hay alternativa, es SOAP o nada

Resultado: No tienes opción, debes usar SOAP

✈️ Caso 3: Reservas de Vuelos (Amadeus GDS)

Contexto: Conectar agencia de viajes con aerolíneas

Por qué SOAP:

  • Protocolo de industria desde los 90s
  • Cientos de aerolíneas ya integradas
  • Transacciones críticas (no puede fallar)
  • Cambiar sería extremadamente costoso

Resultado: Industria completa usa SOAP

REST en Acción

📱 Caso 1: App de Instagram

Contexto: Millones de usuarios subiendo fotos diariamente

Por qué REST:

  • Necesita ser ultra rápido
  • Bajo consumo de datos móviles
  • JSON es ligero y fácil de parsear
  • Múltiples plataformas (iOS, Android, Web)
  • Caché HTTP para optimizar carga

Resultado: REST es perfecto para esto

🗺️ Caso 2: Google Maps API

Contexto: Desarrolladores de todo el mundo usan la API

Por qué REST:

  • Fácil de integrar en cualquier lenguaje
  • Documentación simple y clara
  • Respuestas JSON fáciles de consumir
  • Millones de requests por segundo
  • Excelente experiencia de desarrollador

Resultado: API pública más usada del mundo

🛒 Caso 3: E-commerce (Amazon, Mercado Libre)

Contexto: Tienda online con millones de productos

Por qué REST:

  • Catálogo gigante que se actualiza constantemente
  • Necesita ser escalable horizontalmente
  • Múltiples clientes (web, móvil, apps de terceros)
  • Búsquedas y filtros complejos
  • Caché agresivo para productos populares

Resultado: REST permite crecer sin límites

🐛7. Problema Común: DEBUG = False

Error típico en Django:

❌ Configuración incorrecta en settings.py 
26 | DEBUG = False
27 |
28 | ALLOWED_HOSTS = []   # ← Este es el problema

¿Por qué falla?

El problema es que tienes DEBUG = False en la línea 26, pero ALLOWED_HOSTS = [] en la línea 28.

¿Por qué es necesario?

Cuando DEBUG = False (modo producción), Django requiere que definas ALLOWED_HOSTS por seguridad, para prevenir ataques de tipo "HTTP Host Header". Esto evita que el servidor responda a solicitudes maliciosas con hosts falsos.

✅ Solución: Dos opciones

Opción 1: Modo Desarrollo

✅ Para desarrollo local 
DEBUG = True
ALLOWED_HOSTS = []

Usa esto cuando:

  • Estás desarrollando localmente
  • Necesitas ver errores detallados
  • Estás en tu computadora personal

Opción 2: Modo Producción

✅ Para servidor/Docker 
DEBUG = False
ALLOWED_HOSTS = [
    'localhost',
    '127.0.0.1',
    'tudominio.com',
    '*'  # Solo para testing, NO en producción real
]

Usa esto cuando:

  • Despliegas en servidor
  • Usas Docker
  • Ya está en producción

⚠️ Advertencia de Seguridad

NUNCA uses ALLOWED_HOSTS = ['*'] en producción real. Especifica siempre los dominios exactos: 

ALLOWED_HOSTS = [
    'biblioteca.miempresa.com',
    'www.biblioteca.miempresa.com',
]

🎓8. Conclusión y Recomendaciones

Conclusión para tu proyecto de Biblioteca

En tu sistema de biblioteca con Django y Docker:

  • ✅ Quédate con REST para todo lo nuevo que construyas
  • ⚠️ Entiende SOAP solo como una herramienta que usarás si te ves obligado a conectarte con un sistema externo viejo o muy burocrático

Recomendaciones Finales

📱

Para Apps Modernas

Usa: REST + JSON

Es el estándar actual. 80% del mercado lo usa.

🏦

Para Sistemas Financieros

Usa: SOAP + XML

Obligatorio en banca y gobierno. No hay elección.

🔄

Para Integraciones B2B

Depende del socio

Pregunta qué prefieren. Adapta tu sistema.

📚

Para Aprender

Aprende ambos

En este proyecto tienes REST y SOAP implementados.

¿Qué librería de Python usar para SOAP?

Si algún día necesitas conectar Django con un servicio SOAP, estas son las mejores opciones:

1. Zeep (Recomendado) 🏆

pip install zeep

from zeep import Client

# Conectar al servicio SOAP
client = Client('http://ejemplo.com/servicio?wsdl')

# Llamar a un método
resultado = client.service.obtenerLibro(libro_id=5)
print(resultado)

Ventajas: Moderno, rápido, bien documentado

2. Spyne (Para crear servicios SOAP)

pip install spyne

# Ya lo usas en tu proyecto para crear el servicio SOAP
# Archivo: libros/soap_services.py

Uso: Para crear APIs SOAP en Django

3. suds-py3 (Alternativa)

pip install suds-py3

from suds.client import Client
client = Client('http://ejemplo.com/servicio?wsdl')

Nota: Más antiguo, pero aún funciona

"Si estás generando aplicaciones SOAP hoy en día para un proyecto nuevo y sencillo, probablemente te estás complicando la vida innecesariamente; REST (con Django REST Framework) es mucho más rápido de desarrollar y mantener."

— Principio de pragmatismo en desarrollo

📊 Estadísticas del Mercado 2026

Métrica REST SOAP
Nuevos proyectos 85% 15%
APIs públicas 95% 5%
Sector financiero 30% 70%
Startups 99% 1%
Empresas Fortune 500 60% 40%

📝Resumen Ejecutivo

🚀 REST

Lo que debes saber:

  • Usa JSON (ligero)
  • Basado en HTTP
  • Fácil de aprender
  • Perfecto para apps modernas
  • 80%+ del mercado actual

→ Tu elección por defecto

📋 SOAP

Lo que debes saber:

  • Usa XML (pesado)
  • Protocolo estricto
  • Complejo pero seguro
  • Para bancos y gobierno
  • 15-20% del mercado

→ Solo si te lo exigen

🎓 Es importante Saber Para esta Unidad 3

Debes saber explicar:

  • ✅ Diferencias entre SOAP y REST
  • ✅ Cuándo usar cada uno
  • ✅ Ventajas y desventajas
  • ✅ Aspectos de seguridad
  • ✅ Ejemplos de uso real

🎓 Resumen Teórico Unidad 3

SOAP: Estricto, seguro, XML, WS-Security, para bancos y gobierno

REST: Flexible, rápido, JSON, HTTPS+tokens, para apps modernas

Sistema de Gestión de Biblioteca - Unidad 3
Servicios Web - UTH 2026-1

📚 Proyecto educativo con implementación completa de SOAP y REST
Actualizado: Febrero 2026