4. HTTP (Hypertext Transfer Protocol)

El protocolo HTTP es el idioma que habla la mayor parte de la Web. Define cómo un cliente formula una solicitud y cómo un servidor responde con documentos, APIs o eventos en tiempo real.

Su diseño sin estado facilita la escalabilidad y lo vuelve ideal para servicios distribuidos. Todas las mejoras posteriores, desde el streaming hasta las aplicaciones de una sola página, siguen apoyándose en el mismo contrato básico establecido por los navegadores y servidores web.

4.1 Protocolo principal de la Web

HTTP describe un modelo cliente-servidor en el que el navegador, una aplicación móvil o un bot abre una conexión (por lo general sobre TCP) y envía un mensaje de texto estructurado. Algunas implementaciones también pueden operar sobre UDP cuando se requiere menor latencia, como ocurre con HTTP/3.

Las especificaciones actuales de HTTP son mantenidas por el IETF, mientras que organismos como el W3C definen cómo los navegadores combinan este protocolo con estándares como HTML y hojas de estilo. También se apoya en arquitecturas como REST para describir interacciones recurrentes entre clientes y servidores.

Aunque se lo considera sin estado, los desarrolladores agregan registros de sesión mediante cookies, tokens o cabeceras personalizadas que reconstruyen el contexto del usuario en cada solicitud.

4.2 Flujo de solicitudes y respuestas

Cada transacción HTTP sigue un ciclo sencillo:

  1. El cliente resuelve la dirección IP del servidor y abre un socket.
  2. Envía una solicitud con un método, una ruta y cabeceras opcionales.
  3. El servidor procesa la solicitud, busca el recurso y genera una respuesta con un código de estado.
  4. Ambas partes deciden si reutilizar la conexión (keep-alive) o cerrarla.

Los métodos expresan la intención del cliente. Los más empleados se resumen en la siguiente tabla:

Método Acción Características
GET Obtiene un recurso sin modificarlo. Debe ser seguro e idempotente; se cachea fácilmente.
POST Envía datos para crear o procesar información. No es idempotente; frecuentemente transporta formularios o JSON.
PUT Reemplaza por completo un recurso en la ruta indicada. Es idempotente y requiere cuerpo con el estado final.
PATCH Modifica parcialmente un recurso existente. Ideal para cambios incrementales con menor consumo de ancho de banda.
DELETE Borra el recurso apuntado. Debe confirmar si el borrado fue exitoso con un código 2xx o 404 si no existía.
OPTIONS Consulta las capacidades del servidor para una ruta. Es clave para negociaciones CORS y descubrimiento de APIs.

A partir de estos métodos se construyen APIs REST, servicios SOAP y notificaciones que automatizan flujos corporativos completos.

4.3 Estructura de un mensaje HTTP

Los mensajes poseen tres bloques principales que el cliente y el servidor deben respetar para mantener la interoperabilidad:

Bloque Contenido Ejemplo
Línea inicial Indica el método y la versión en solicitudes, o el código de estado en respuestas. GET /api/v1/pedidos HTTP/1.1 / HTTP/1.1 200 OK
Cabeceras Par clave-valor con datos de contexto (autenticación, caché, tipo de contenido, fechas). Content-Type: application/json
Cuerpo Opcional; contiene la representación del recurso en formatos como JSON, XML o binario. {"total": 125.70}

De esta combinación surgen los códigos de estado que permiten diagnosticar cada respuesta:

  • 1xx: respuestas informativas que continúan el proceso.
  • 2xx: éxito (200 OK, 201 Created).
  • 3xx: redirecciones temporales o permanentes.
  • 4xx: errores atribuibles al cliente (400 Bad Request, 404 Not Found).
  • 5xx: fallas del servidor (500 Internal Server Error, 503 Service Unavailable).

El fragmento siguiente muestra una solicitud y una respuesta completas para una API de ejemplo: 

GET /api/v1/pedidos?estado=en-proceso HTTP/1.1
Host: api.fabrica.local
Accept: application/json
Cache-Control: no-cache
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

HTTP/1.1 200 OK
Date: Tue, 12 Nov 2025 18:20:01 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 148
ETag: "9db-11ee"

{
  "total": 3,
  "registros": [
    {"id": 501, "prioridad": "alta"},
    {"id": 502, "prioridad": "media"},
    {"id": 503, "prioridad": "baja"}
  ]
}

4.4 Versiones: HTTP/1.1, HTTP/2 y HTTP/3

La evolución del protocolo busca reducir latencia, mejorar la seguridad y optimizar el uso del ancho de banda. Las diferencias clave se resumen abajo:

Versión Innovaciones Casos típicos
HTTP/1.1 Conexiones persistentes, canalizaciones limitadas, cabeceras de control de cache mejor definidas. Aplicaciones legadas, servidores sencillos o APIs internas.
HTTP/2 Multiplexación binaria en una sola conexión TCP, compresión de cabeceras HPACK y servidor push. Sitios con muchos recursos estáticos o APIs de alto volumen.
HTTP/3 Se ejecuta sobre QUIC, evitando bloqueo de cabecera de línea y mejorando la recuperación ante pérdida de paquetes. Servicios globales que necesitan baja latencia (streaming, juegos, videoconferencias).

Migrar a versiones recientes suele requerir soporte del balanceador de carga y de los navegadores destino, pero trae beneficios tangibles en tiempos de carga y uso de CPU.

4.5 Limitaciones de HTTP sin cifrar

HTTP tradicional transporta todo en texto plano, lo que expone varios riesgos:

  • Falta de confidencialidad: cualquier intermediario puede leer credenciales y datos personales.
  • Integridad vulnerable: un atacante puede modificar respuestas e inyectar contenido malicioso.
  • No autenticación: el cliente no tiene forma de verificar la identidad del servidor.
  • Dificultad para cumplir normativas: legislaciones de privacidad exigen cifrado extremo a extremo.

Estas limitaciones se resuelven combinando HTTP con TLS, tema central del siguiente capítulo dedicado a HTTPS.

4.6 Práctica con herramientas y automatización

Desde Windows, PowerShell permite probar métodos y analizar cabeceras sin instalar software extra: 

Invoke-WebRequest -Uri "http://httpbin.org/get" `
  -Method Get `
  -Headers @{ "Accept" = "application/json"; "Cache-Control" = "no-cache" } `
  | Select-Object StatusCode, Headers, Content

El comando anterior devuelve el código de estado, las cabeceras y el cuerpo, ayudando a verificar la coherencia de la API y la presencia de mecanismos de cache.

También es habitual automatizar consultas con Python para monitorear servicios o preparar datos de prueba: 

import http.client
import json

conn = http.client.HTTPConnection("httpbin.org", 80, timeout=5)
payload = json.dumps({"usuario": "soporte", "operacion": "ping"})
conn.request("POST", "/post", body=payload, headers={"Content-Type": "application/json"})
response = conn.getresponse()
print(response.status, response.reason)
print(response.getheader("Content-Type"))
print(response.read(120).decode("utf-8"))
conn.close()

Estas rutinas se integran en pipelines de despliegue continuo para asegurar que cada endpoint responda antes de liberar una nueva versión del software.

4.7 Cierre

HTTP ha demostrado ser flexible y robusto durante décadas. Comprender sus métodos, códigos y versiones permite diseñar APIs más predecibles, diagnosticar cuellos de botella y justificar la adopción de HTTP/2 o HTTP/3 cuando la aplicación lo necesite. En el próximo tema profundizaremos en HTTPS, donde el cifrado se suma al protocolo para proteger los datos que viajan por la red.

Retornar