HTTP organiza peticiones y respuestas entre clientes y servidores
HTTP es el protocolo de la capa de aplicación que define cómo un cliente solicita recursos o acciones y cómo un servidor responde. Cuando un navegador abre una página, pide primero el HTML y después puede solicitar CSS, JavaScript, imágenes y datos. Cada intercambio contiene un mensaje de petición y otro de respuesta. HTTP define su significado; no es el lenguaje HTML, el sistema DNS ni el cable por el que viajan. Sus reglas permiten que navegadores, aplicaciones, cachés y servidores distintos entiendan la intención de cada mensaje sin compartir una implementación.
Una URL identifica el recurso y aporta esquema, host, ruta y quizá consulta. DNS traduce el nombre del host a direcciones de red antes de la conexión. El transporte entrega los mensajes: HTTP/1.1 y HTTP/2 suelen usar TCP; HTTP/3 emplea QUIC sobre UDP. Estas capas cooperan, pero resolver un dominio, establecer una conexión y pedir `/articulo.html` son operaciones distintas.
Método, ruta, cabeceras y cuerpo describen la petición
Una petición incluye un método como GET, POST, PUT, PATCH o DELETE, el destino y cabeceras. GET solicita una representación y debería ser seguro; PUT reemplaza un estado de forma idempotente; POST procesa contenido según las reglas del recurso y no promete idempotencia. Esas son semánticas, no permisos automáticos. Un servidor debe autenticar y autorizar aunque el cliente cambie el nombre del método.
Las cabeceras transportan metadatos: tipos aceptados, idioma, credenciales, control de caché o condiciones. El cuerpo puede contener un formulario, JSON o un archivo, pero no todos los métodos lo usan igual. `Content-Type` describe el formato enviado; `Accept` expresa formatos deseados en la respuesta. Interpretarlos correctamente permite que cliente y servidor evolucionen sin adivinar el contenido por su extensión.
El código de estado resume el resultado; no sustituye el cuerpo
La respuesta contiene código, cabeceras y quizá cuerpo. Los códigos 2xx indican éxito; 3xx redirección; 4xx un problema relacionado con la petición; 5xx un fallo del servidor al atenderla. `200` no significa que los datos sean verdaderos, solo que la operación HTTP se procesó con éxito. `404` indica que no se encontró una representación; `401` pide autenticación y `403` rechaza el acceso.
Las redirecciones permanentes y temporales afectan navegación y caché de manera distinta. Cabeceras como ETag y Last-Modified permiten peticiones condicionales: si el recurso no cambió, el servidor puede responder `304` sin reenviar el cuerpo. La caché reduce latencia y tráfico, pero necesita reglas correctas para no mostrar información privada u obsoleta. HTTP es extensible precisamente porque nuevas cabeceras pueden añadir comportamiento conservando la estructura básica.
HTTP no recuerda peticiones anteriores, pero las aplicaciones construyen sesiones
El protocolo es sin estado: una petición no conoce automáticamente la anterior. Las aplicaciones añaden continuidad mediante cookies, tokens o identificadores. Un servidor puede enviar `Set-Cookie`; el navegador devuelve la cookie en peticiones compatibles con dominio, ruta y políticas. La cookie suele contener un identificador, no necesariamente todos los datos de la sesión. El estado real puede residir en el servidor o dentro de un token firmado.
Atributos `Secure`, `HttpOnly` y `SameSite` reducen ciertos riesgos, pero no sustituyen diseño seguro. Una cookie robada puede permitir suplantación; una petición desde otro sitio puede intentar aprovechar una sesión existente. Caducidad, rotación, protección CSRF y política de origen forman parte del sistema. Decir que HTTP “no tiene sesiones” es correcto en el núcleo y falso si se usa para negar las capas que la web construye encima.
HTTPS protege el canal; HTTP conserva la semántica
HTTPS es HTTP transportado dentro de TLS. Cifra el tráfico, ayuda a detectar alteraciones y autentica al servidor mediante certificados. No demuestra que el contenido sea honesto ni evita todos los ataques de una aplicación. También protege ruta y cabeceras después de establecer el canal, aunque terceros todavía pueden observar cierta información de conexión. Una página con candado puede seguir siendo fraudulenta.
HTTP/2 comprime cabeceras y multiplexa varias secuencias en una conexión; HTTP/3 traslada esa idea a QUIC y reduce ciertos bloqueos del transporte. Las versiones cambian representación y rendimiento, pero mantienen métodos, estados y cabeceras reconocibles. Comprender HTTP consiste en seguir una conversación: quién pide qué, con qué condiciones, qué responde el servidor y qué puede guardar cada intermediario. Esa trazabilidad permite diagnosticar desde un `404` hasta una caché o autenticación defectuosa.
Las API usan HTTP sin que cada ruta sea automáticamente REST. Un diseño RESTful trata recursos mediante representaciones y semánticas uniformes, pero muchas API emplean acciones o RPC sobre el mismo transporte. El cuerpo JSON tampoco pertenece al protocolo: es un formato negociado. CORS, por su parte, es una política de navegador basada en cabeceras que controla qué respuestas puede leer un script de otro origen; no bloquea peticiones de servidores ni sustituye autorización. Separar estas ideas evita diagnosticar como “fallo de HTTP” lo que en realidad ocurre en DNS, TLS, aplicación, caché o política de origen. Las herramientas de red del navegador permiten ver esta secuencia completa y comprobar tiempos, cabeceras, caché y respuestas en lugar de imaginar qué parte del sistema falló. Leer esos mensajes convierte un error opaco en una hipótesis técnica que puede comprobarse.
