El viaje de una petición HTTP

Diseño de interfaz

Leyenda de líneas: el sistema de color

En un mapa de metro real, el color identifica la línea sin ambigüedad. Aquí pasa lo mismo: cada color de acento queda fijo a un concepto —la familia de código de estado que representa— y se repite en toda la navegación, las tarjetas y los diagramas, para que reconocer un color sea reconocer una idea.

Línea A · Conceptos básicos

Arquitectura cliente-servidor

HTTP se apoya en un paradigma estricto: el cliente abre la conexión y envía una petición; el servidor escucha, procesa y responde. Es un ciclo atómico e independiente que se repite en cada intercambio, como cada viaje de un tren entre dos estaciones.

HTTP es stateless (sin estado): el servidor no recuerda peticiones anteriores. Esto simplifica el diseño y facilita escalar, pero obliga a usar cookies o tokens —el "boleto" que el cliente muestra en cada viaje— para mantener la sesión.

Anatomía del boleto (mensaje HTTP)

Línea B · Verbos HTTP

Métodos como paradas de la línea

Cada verbo es una parada con una función fija. Usar la parada correcta habilita ventajas automáticas, como el caché de los GET.

Ejemplo práctico con JavaScript

La Fetch API del navegador emite peticiones HTTP reales desde JavaScript. Estos ejemplos muestran un boleto de ida GET y uno de creación POST:

fetch("https://api.ejemplo.com/usuarios/12")
  .then(function (response) { return response.json(); })
  .then(function (data) { console.log(data); })
  .catch(function (error) { console.error("Error:", error); });

fetch("https://api.ejemplo.com/usuarios", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ nombre: "Ana", correo: "ana@ejemplo.com" })
})
  .then(function (response) { return response.json(); })
  .then(function (data) { console.log("Creado:", data); });

Línea C · Anatomía de la respuesta

Tablero de salidas: códigos de estado

Como en un tablero de aeropuerto, cada código de tres dígitos anuncia de inmediato el resultado del viaje. El primer dígito indica la familia.

Aporte personal: los códigos de estado son la verdadera interfaz de usuario de una API. Devolver siempre 200 OK con un error encapsulado en el JSON es un antipatrón: usar el código correcto facilita la depuración y hace el software más predecible.

Línea D · Historia y seguridad

Tres vías hacia HTTP/3, y la terminal HTTPS

Piensa en HTTP/1.1, HTTP/2 y HTTP/3 como tres vías que salieron en distintas épocas pero llegan a la misma terminal: una comunicación más rápida y segura entre cliente y servidor.

Terminal HTTPS: HTTP sobre TLS

HTTPS no es una vía distinta, sino HTTP circulando sobre una capa de cifrado SSL/TLS. Toda ruta segura pasa por tres andenes:

Cuando los cimientos como TCP se vuelven un cuello de botella, a veces la única forma de avanzar es tender una vía nueva —esa es la lección de HTTP/3. Hoy, HTTPS dejó de ser un lujo de pasarelas de pago para convertirse en el estándar mínimo de cualquier transmisión de datos.

Para consultar rápido

Glosario de la ruta

Términos que aparecen en el recorrido, explicados en una línea. Haz clic en cada uno para expandirlo.

Navegación

Mapa completo de la red

Estación central → 4 líneas de contenido

Fuentes consultadas

Referencias bibliográficas

• 01Fielding, R., & Reschke, J. (2014). Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Internet Engineering Task Force (IETF). tools.ietf.org/html/rfc7230
• 02Gourley, D., & Totty, B. (2002). HTTP: The Definitive Guide. Sebastopol, CA: O'Reilly Media, Inc.
• 03Mozilla Developer Network. (2023). An overview of HTTP. MDN Web Docs. developer.mozilla.org/es/docs/Web/HTTP/Overview