Definición
HTTP (HyperText Transfer Protocol) es el protocolo fundamental de la World Wide Web y las APIs modernas. Cada vez que visitas un sitio web, transmites un video o usas una aplicación móvil, HTTP está trabajando detrás de escena para transferir datos entre tu dispositivo (el cliente) y servidores remotos.
HTTP es un protocolo petición-respuesta. El cliente envía una petición (como “dame la página principal”), y el servidor responde (con el HTML, imágenes, datos, etc.). HTTP es sin estado (stateless): cada petición es independiente, el servidor no recuerda peticiones previas. Esta simplicidad hace que HTTP sea increíblemente escalable.
HTTP opera sobre TCP/IP, típicamente usando el puerto 80. El protocolo define métodos (GET, POST, PUT, DELETE) para diferentes tipos de peticiones, códigos de estado (200 OK, 404 Not Found) para indicar resultados, y cabeceras para pasar metadatos. Aunque originalmente diseñado para transferir documentos de hipertexto, HTTP ha evolucionado hacia el protocolo universal para APIs y servicios web.
Ejemplo
Navegación Web: Cuando escribes example.com en tu navegador, envía GET / [HTTP/1.1](https://reference.apios.info/es/terms/http-1-1/) al servidor. El servidor responde con HTTP/1.1 200 OK más el contenido HTML. Cada imagen, archivo CSS y script en esa página dispara peticiones HTTP adicionales.
API de Aplicación Móvil: Una aplicación de clima envía GET /api/weather?city=NYC HTTP/1.1 para obtener condiciones actuales. El servidor responde con HTTP/1.1 200 OK y datos JSON conteniendo temperatura, humedad y pronóstico.
Subida de Archivo: Cuando subes una foto de perfil, la aplicación envía POST /api/users/123/avatar HTTP/1.1 con los datos de imagen en el cuerpo de la petición. El servidor responde con HTTP/1.1 201 Created y la nueva URL de imagen.
Integración de API: La API de Slack usa HTTP para todas las interacciones. Publicar un mensaje es POST /api/chat.postMessage con el texto del mensaje. Obtener historial de canal es GET /api/conversations.history?channel=C1234. Todo sobre HTTP.
Analogía
El Sistema de Pedidos del Restaurante: HTTP es como ordenar en un restaurante:
- Tú (cliente) haces una petición: “Me gustaría la hamburguesa, término medio”
- La cocina (servidor) la procesa y envía una respuesta: Tu hamburguesa llega
- Cada pedido es independiente: el camarero no necesita recordar lo que pediste la semana pasada
- El menú es como la documentación de API, mostrando opciones disponibles (métodos HTTP)
- El número de ticket es como un ID de petición para rastreo
- La entrega de comida es como el cuerpo de respuesta con tus datos
La Oficina Postal: Enviar cartas vía HTTP:
- Escribes una carta (cuerpo de petición) con una dirección (URL)
- Eliges un tipo de servicio (método HTTP): correo regular (GET), certificado (POST), acuse de recibo (PUT)
- El servicio postal la entrega al destino (servidor)
- Recibes una respuesta: confirmación de entrega (200 OK) o “dirección no encontrada” (404)
- Cada carta es independiente: sin memoria de envíos previos (sin estado)
Ejemplo de Código
// Petición HTTP
GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
// Respuesta HTTP
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
Cache-Control: max-age=300
{
"id": 123,
"name": "Alice",
"email": "[email protected]",
"created": "2025-01-01T00:00:00Z"
}
Diagrama
sequenceDiagram participant Client participant Server Client->>Server: Petición HTTP
GET /api/resource Server->>Server: Procesar petición Server->>Client: Respuesta HTTP
200 OK + Datos Note over Client,Server: Sin estado: cada petición es independiente
Notas de Seguridad
CRÍTICO - …
Configuración y Validación:
- El tráfico HTTP no está encriptado y puede ser interceptado.
- Nunca transmitir datos sensibles (contraseñas, tokens, información personal) sobre HTTP plano.
- Siempre usar HTTPS para APIs en producción.
- Implementar autenticación apropiada (OAuth 2.0, JWT) en cabeceras, no en URLs.
- Validar todas las entradas para prevenir ataques de inyección.
Monitoreo y Protección:
- Usar cabeceras CORS para controlar peticiones cross-origin.
- Establecer cabeceras de seguridad (Strict-Transport-Security, X-Content-Type-Options).
- Aplicar limitación de tasa para prevenir abuso.
- Registrar todas las operaciones PATCH para pistas de auditoría.
- HTTP es vulnerable a ataques man-in-the-middle sin encriptación.
Mejores Prácticas
- Usar HTTPS, no HTTP, para todo el tráfico en producción
- Elegir métodos HTTP apropiados (GET para lectura, POST para creación, PUT/PATCH para actualización, DELETE para eliminación)
- Devolver códigos de estado correctos (200 para éxito, 404 para no encontrado, 500 para error de servidor)
- Incluir cabeceras relevantes (Content-Type, Cache-Control, Authorization)
- Mantener peticiones sin estado: no depender de sesiones del lado del servidor
- Versionar tus APIs en la URL o cabeceras
- Implementar manejo de errores apropiado con mensajes descriptivos
- Usar compresión (gzip, br) para respuestas grandes
Errores Comunes
Usar HTTP en lugar de HTTPS para datos sensibles, devolver 200 para todas las respuestas (incluso errores), poner credenciales en parámetros de URL, no establecer cabeceras Content-Type, ignorar cabeceras de cacheo, no implementar timeouts, exponer errores internos a clientes, no validar entradas, configuración CORS faltante.