La Web de Tim Berners-Lee: URLs, HTTP, HTML y por qué importa

Qué es (y qué no es) la World Wide Web

La World Wide Web (a menudo solo “la Web”) es una manera de publicar y acceder a información usando enlaces. Es el sistema que te permite hacer clic de una página a otra, abrir la página de un producto desde un resultado de búsqueda o compartir un enlace que funciona en casi cualquier ordenador o teléfono.

La Web se construye sobre tres ideas sencillas

En su núcleo, la Web se apoya en un trío práctico:

• URL (Localizador Uniforme de Recursos): la dirección de algo en la Web (una página, una imagen, un archivo, un endpoint).
• HTTP (Hypertext Transfer Protocol): la conversación de entrega—cómo un navegador pide algo y cómo responde un servidor.
• HTML (HyperText Markup Language): el formato de página—una manera estructurada de describir contenido y, lo más importante, enlaces a otras URLs.

No necesitas ser programador para notar su impacto: cada vez que pegas un enlace, cargas una página o haces clic en un botón que te lleva a otro sitio, estás usando URL + HTTP + HTML.

La Web vs. la Internet (no son lo mismo)

La gente suele usar “Web” e “Internet” como si fuesen intercambiables, pero son diferentes:

• La Internet es la infraestructura subyacente: una red global de ordenadores conectados.
• La Web es un servicio que corre encima de esa infraestructura: una colección enlazada de recursos a los que se accede usando URLs y HTTP, normalmente mostrados en HTML.

El correo electrónico, los juegos en línea y muchas apps de chat usan la Internet sin ser “la Web” en sentido estricto.

Por qué esto sigue siendo importante

Incluso las experiencias modernas—aplicaciones de una sola página, apps móviles y APIs—dependen en gran medida de estos cimientos. Pueden ocultar los detalles, pero siguen usando URLs para identificar recursos, HTTP para intercambiar peticiones y respuestas y, a menudo, HTML para arrancar lo que ves en un navegador.

El problema que Tim Berners-Lee quiso resolver

Tim Berners-Lee no trataba de inventar “la internet”. En 1989, mientras trabajaba en el CERN, se enfocó en una frustración práctica: la información importante existía, pero estaba dispersa entre sistemas incompatibles, almacenada en distintos formatos y era difícil de encontrar después.

Investigadores, equipos y departamentos usaban ordenadores y software distintos. Incluso cuando dos grupos tenían el “mismo” tipo de documento, podían guardarlo en lugares diferentes, nombrarlo de otra manera o requerir un programa especial para abrirlo. Compartir a menudo significaba enviar archivos, duplicar copias y perder la pista de cuál era la versión vigente.

Un objetivo simple: hacer la información enlazable y compartible

La idea central de Berners-Lee fue permitir que cualquiera publicara un documento en su propio ordenador y que otros pudieran acceder a él con un método consistente—sin necesitar saber el tipo de máquina, el sistema operativo o la estructura interna de directorios.

Eso requirió que varias cosas funcionaran juntas:

• Una forma de nombrar y localizar información de manera consistente (direcciones).
• Una forma básica de solicitar y recibir esa información a través de redes.
• Un formato de documento ligero que pudiera incluir enlaces a otros documentos.

Simplicidad e interoperabilidad primero

El avance no fue una sola función—fue la decisión de mantener el sistema pequeño y universal. Si las reglas eran lo bastante simples, distintos ordenadores y organizaciones podían implementarlas y aun así comunicarse.

Por eso las normas abiertas importaron desde el inicio: la web necesitaba reglas compartidas y públicas para que muchos sistemas independientes participaran. Ese enfoque en estándares comunes—en lugar de la cadena de herramientas de un único proveedor—hizo posible que la web se difundiera rápidamente y que nuevos navegadores y servidores funcionaran con contenido existente.

URLs: el sistema de direcciones para la Web

Si alguna vez has intentado “compartir un archivo” en una unidad de oficina desordenada, habrás visto el problema central de las redes: nombrar cosas de forma consistente es difícil. Diferentes ordenadores almacenan información en lugares distintos, las carpetas se reorganizan y dos documentos pueden tener el mismo nombre. Sin un sistema de nombres compartido, no puedes decir con fiabilidad “consigue esa cosa de allí”.

Las URLs resolvieron esto para la World Wide Web ofreciendo una dirección universal, copiables y pegables, para un recurso.

Una URL que puedes leer

Aquí tienes un ejemplo que quizá reconozcas:

https://www.example.com:443/products/shoes?color=blacksize=42#reviews

Qué significa cada parte (en palabras sencillas):

• https — el esquema: qué reglas usar para obtenerlo (HTTP sobre cifrado).
• www.example.com — el host: con qué servidor hablar.
• :443 — el puerto (a menudo implícito, así que suele ocultarse).
• /products/shoes — la ruta: qué recurso en ese servidor.
• ?color=blacksize=42 — la consulta: parámetros extra (a menudo para filtrar o rastrear).
• #reviews — el fragmento: una posición dentro de la página (lo maneja el navegador).

Las URLs no solo apuntan a “páginas”

Una URL puede identificar casi cualquier cosa que un servidor pueda devolver: una página HTML, una imagen, un PDF, un archivo descargable o incluso un endpoint de API usado por una app.

Por ejemplo:

• /images/logo.png (una imagen)
• /docs/terms.pdf (un documento)
• /api/orders/123 (datos para una aplicación)

URL vs. URI vs. “enlace” (manténlo simple)

La gente suele usar estas palabras indistintamente:

• URL: la “dirección” web que puedes usar para obtener algo.
• URI: un término más amplio que incluye URLs.
• Enlace: lo que clicas—normalmente un texto o botón que contiene una URL.

Para propósitos prácticos, pensar “URL = dirección” te llevará el 95% del camino.

HTTP: el lenguaje de petición y respuesta de la Web

HTTP es el estilo de conversación básico de la web. Es un trato simple: tu navegador pide algo y un servidor responde con lo que tiene (o una explicación de por qué no puede).

La idea central: el navegador pide, el servidor responde

Cuando escribes una URL o haces clic en un enlace, tu navegador envía una petición HTTP a un servidor. La petición es como una nota que dice: “Quiero este recurso específico”.

El servidor entonces envía una respuesta HTTP. La respuesta es el paquete que contiene el resultado: el contenido que pediste (como una página), o un mensaje de que sucedió otra cosa.

Peticiones en términos cotidianos (GET y POST)

Las peticiones HTTP incluyen un método, que es simplemente el tipo de acción que realizas.

• GET: “Por favor, dame esto.” Ejemplo: cargar una página o descargar un archivo.
• POST: “Por favor, acepta estos datos.” Ejemplo: enviar un formulario de registro o publicar un comentario.

Un GET normalmente no cambia nada en el servidor; se usa principalmente para leer. Un POST se usa comúnmente cuando envías información para que se procese.

Códigos de estado: el resultado de la petición

Cada respuesta incluye un código de estado—piénsalo como el resultado de la entrega.

• 200: Éxito. Aquí tienes lo que pediste.
• 404: No encontrado. Ese recurso no existe en esa dirección.
• 301: Movido permanentemente. El recurso tiene una nueva dirección; actualiza tu marcador.

Cabeceras y tipos de contenido: etiquetas en el paquete

Peticiones y respuestas también incluyen cabeceras, que son como etiquetas: “Este soy yo”, “Esto es lo que acepto” o “Así debe manejarse este contenido”.

Una de las etiquetas más útiles es el Content-Type, como text/html para una página web o application/json para datos. Indica al navegador qué hay dentro para que pueda mostrarlo correctamente.

HTML: un formato simple para páginas y enlaces

HTML (HyperText Markup Language) es el formato usado para describir la estructura de una página web—qué contenido hay y cómo está organizado. Piénsalo como un documento con etiquetas: “esto es un encabezado”, “esto es un párrafo”, “esto es un enlace”, “esto es un campo de formulario”.

Etiquetas: marcadores alrededor del contenido

HTML usa etiquetas para marcar el contenido. Una etiqueta suele tener una versión de apertura y otra de cierre, envolviendo el contenido que describe.

Los encabezados y párrafos le dan forma a una página. Un encabezado indica tanto a las personas como a los navegadores: “esta es una sección importante”. Un párrafo les dice: “esto es texto del cuerpo”.

Los enlaces e imágenes también se describen en HTML. Una etiqueta de imagen apunta a un archivo de imagen (un recurso), mientras que una etiqueta de enlace apunta a otra URL.

Hipertexto: por qué los enlaces lo cambiaron todo

Las “HT” en HTML—hipertexto—es la gran idea que hizo que la web se sintiera diferente de sistemas anteriores. En lugar de navegar solo por menús, carpetas o comandos especiales, podías saltar directamente de un documento a otro usando enlaces clicables incrustados en el texto.

Ese cambio suena simple, pero es poderoso: el conocimiento se conecta. Una página puede referenciar fuentes, temas relacionados, definiciones y pasos siguientes al instante—sin necesidad de “volver” a un índice central cada vez.

Un pequeño ejemplo: un enlace en lenguaje sencillo

Aquí tienes cómo se ve un enlace básico:

<a href="/blog/how-http-works">Read more about HTTP</a>

En palabras simples: “Muestra las palabras Read more about HTTP y, cuando se haga clic, lleva al lector a la página en /blog/how-http-works”.

Formularios: de leer a interactuar

HTML no solo sirve para publicar documentos. También puede describir entradas como campos de texto, casillas y botones. Esos elementos permiten que una página recopile información (como un inicio de sesión, una búsqueda o un pago) y la envíe a un servidor.

HTML vs. CSS vs. JavaScript

Es fácil confundirlos, pero tienen trabajos distintos:

• HTML define estructura y significado (encabezados, párrafos, enlaces, formularios).
• CSS controla estilo (colores, espaciado, fuentes, diseño).
• JavaScript agrega comportamiento (validación, actualizaciones dinámicas, funciones interactivas).

Aunque las aplicaciones web se han vuelto más complejas, HTML sigue siendo el punto de partida: es la forma compartida y legible de describir qué contiene una página—y hacia dónde puede llevar.

Cómo se carga una página web: una guía en lenguaje sencillo

Cuando visitas un sitio web, tu navegador hace básicamente dos trabajos: encontrar el ordenador correcto con el que hablar y pedir el archivo correcto.

1) Escribes una URL

Una URL (como https://example.com/page) es la dirección de la página. Incluye un nombre de host (example.com) y, a menudo, una ruta (/page).

2) El navegador encuentra el sitio (búsqueda DNS)

Los ordenadores en internet se comunican usando direcciones numéricas llamadas direcciones IP. DNS (Domain Name System) es como una guía telefónica que mapea example.com a una IP.

Esta búsqueda suele ser rápida—y a veces se omite porque la respuesta ya está almacenada de una visita reciente.

3) El navegador se conecta a ese ordenador

Ahora el navegador abre una conexión al servidor en esa dirección IP. Si la URL empieza con https://, el navegador también establece una conexión cifrada para que otros no puedan leer fácilmente lo que se envía.

4) El navegador solicita usando HTTP

HTTP (Hypertext Transfer Protocol) es el lenguaje de “petición y respuesta” de la web. El navegador envía una petición HTTP como: “Por favor, dame /page.”

El servidor responde con una respuesta HTTP que incluye un estado (como “OK” o “Not Found”) y el contenido.

5) El navegador recibe HTML y renderiza la página

Ese contenido suele ser HTML (HyperText Markup Language). HTML es un formato simple que describe la estructura de una página—encabezados, párrafos, enlaces y más.

Mientras el navegador lee el HTML, puede descubrir que también necesita otros archivos (CSS para estilos, JavaScript para interacción, imágenes, fuentes). Entonces repite el mismo patrón de petición/respuesta HTTP por cada uno.

6) Caché: “guardar una copia para cargar más rápido”

Para acelerar las cosas, los navegadores guardan un caché—una copia guardada de archivos descargados anteriormente. Si nada ha cambiado, el navegador puede reutilizar esa copia en lugar de descargarla de nuevo.

Checklist rápida (el flujo):

• Introducir URL
• DNS encuentra la dirección IP
• El navegador se conecta (y cifra si es HTTPS)
• Petición HTTP por una ruta/recurso
• El servidor envía HTML (más otros archivos)
• El navegador renderiza; el caché ayuda en cargas futuras

Servidores, navegadores y recursos: los roles básicos

Cuando la gente dice “la web”, a menudo se refiere a una experiencia fluida: tocas un enlace y aparece una página. Debajo de eso, es una relación simple entre tres ideas: servidores, navegadores y recursos.

Servidores: dónde viven las cosas

Un servidor es un ordenador (o un conjunto de ordenadores) conectado a internet que alberga recursos en URLs. Si una URL es una dirección, el servidor es el lugar que recibe visitantes en esa dirección y decide qué devolver.

Esa “cosa” que el servidor envía puede ser una página web, un archivo o datos. El punto clave es que el servidor está configurado para responder a peticiones por URLs específicas.

Navegadores: donde se solicitan y muestran las cosas

Un navegador es un programa (como Chrome, Safari o Firefox) que obtiene recursos de servidores y los muestra de manera legible para humanos.

Cuando introduces una URL o haces clic en un enlace, el navegador:

• pide a un servidor el recurso en esa URL
• recibe una respuesta
• la renderiza (para HTML) o la guarda/usa (para imágenes, descargas y más)

Recursos: lo que se transfiere

Un recurso es cualquier cosa que la web puede identificar y entregar en una URL. Ejemplos comunes incluyen:

• documentos (páginas HTML)
• imágenes (PNG, JPEG, SVG)
• scripts (archivos JavaScript)
• estilos (archivos CSS)
• APIs (endpoints que devuelven datos, a menudo JSON)

Este mismo modelo no se limita a navegadores. Una app móvil también puede solicitar una URL—típicamente un endpoint de API—y recibir datos para mostrarlos en su propia interfaz. Los roles siguen siendo los mismos: app como el “cliente”, servidor como el “anfitrión” y la respuesta de la API como el recurso.

De documentos a interacción: formularios y datos

Las primeras páginas web mostraban información. Los formularios permiten que la web recopile información—convirtiendo una página en una conversación bidireccional.

Qué hace realmente un formulario

Un formulario HTML es un conjunto estructurado de campos (como cajas de texto, casillas y botones) más dos instrucciones clave:

• Dónde enviar los datos (la URL del action)
• Cómo enviarlos (el method, normalmente GET o POST)

Al hacer clic en “Enviar”, el navegador empaqueta lo que escribiste y lo envía usando HTTP al servidor en esa URL. Ese es el puente entre “un documento con campos” y “una aplicación que procesa entradas”.

GET vs POST (la diferencia práctica)

A alto nivel:

• GET adjunta los datos del formulario a la URL como una cadena de consulta (útil para búsquedas y filtros). El resultado es fácil de poner en favoritos y compartir.
• POST envía los datos del formulario en el cuerpo de la petición HTTP (comúnmente usado cuando se crea o cambia algo, como una cuenta o un pedido).

Así, una búsqueda podría verse como /search?q=shoes (GET), mientras que un envío de compra podría POSTear los detalles del pedido a /checkout.

Cómo “maneja” el servidor un formulario

En el servidor, un programa recibe la petición HTTP, lee los valores enviados y decide qué hacer:

• Validar entradas (campos obligatorios, formato de email)
• Comprobar credenciales (inicios de sesión)
• Crear registros (registro de usuarios, tickets de soporte)
• Cobrar y confirmar pedidos (checkout)

El servidor responde—a menudo con una nueva página HTML (“¡Gracias!”), un mensaje de error o una redirección a otra URL.

Nota rápida de seguridad: por qué HTTPS importa

Si un formulario incluye algo sensible—contraseñas, direcciones, datos de pago—HTTPS es esencial. Evita que otros en la red lean o alteren lo que se envía entre tu navegador y el sitio. Sin él, incluso un formulario de inicio de sesión simple puede exponer a los usuarios.

Por qué las apps modernas siguen dependiendo de URLs, HTTP y HTML

Las “apps” modernas en la Web no son solo páginas. La mayoría son web más código: una página HTML que carga JavaScript y CSS, y luego usa ese código para actualizar lo que ves sin recargar toda la página.

Aunque una app parezca nativa (feeds de desplazamiento infinito, actualizaciones en tiempo real, arrastrar y soltar), sigue dependiendo de los mismos tres bloques que introdujo Tim Berners-Lee.

Las URLs siguen identificándolo todo

Una URL no es solo para “una página”. Es una dirección para cualquier recurso: un producto, un perfil de usuario, una consulta de búsqueda, una foto o un endpoint de “enviar mensaje”. Las buenas apps usan URLs para hacer contenido compartible, guardable y enlazable—comportamiento central de la Web.

HTTP sigue moviendo los mensajes

Tras bambalinas, las apps envían peticiones HTTP y reciben respuestas HTTP, igual que los sitios clásicos. Las reglas son las mismas tanto si recuperas una página HTML como si cargas datos para una parte de la pantalla:

• métodos como GET (leer), POST (enviar), PUT/PATCH (actualizar), DELETE (eliminar)
• códigos de estado como 200, 404, 500
• cabeceras para caché, tipo de contenido y autenticación

Las APIs son “páginas web para datos”

La mayoría de apps modernas hablan con APIs: URLs que devuelven datos—a menudo JSON—sobre HTTP.

Por ejemplo:

• una función de mapas solicita lugares cercanos a una API de mapas
• un flujo de checkout envía detalles de pago a una API de pagos
• un chat carga y publica mensajes a una API de mensajería
• analíticas envía eventos a un endpoint de analítica

HTML sigue importando porque suele ser el punto de partida (y a veces el recurso de reserva). Más ampliamente, la Web es una plataforma de integración: si los sistemas pueden ponerse de acuerdo en URLs y HTTP, pueden conectarse—no importa quién los haya construido.

Una manera práctica de ver estos bloques en acción es crear algo pequeño—por ejemplo, un front end en React que hable con una API JSON y tenga URLs compartibles para pantallas clave. Herramientas como Koder.ai siguen este mismo modelo: describes la app en chat y genera una pila web estándar (React en el front, Go + PostgreSQL en el back), de modo que sigues trabajando con URLs reales, endpoints HTTP y HTML entregado por el navegador—solo con mucho menos trabajo manual.

Estándares y compatibilidad: cómo escala la Web

La Web funciona a escala global porque se basa en estándares compartidos—reglas públicas que permiten a distintos sistemas comunicarse con fiabilidad. Un navegador de una compañía puede solicitar una página a un servidor de otra, alojado en cualquier lugar y escrito en cualquier lenguaje, porque acuerdan fundamentos como URLs, HTTP y HTML.

Por qué importan los estándares

Sin estándares, cada sitio necesitaría una app personalizada para verlo y cada red tendría su forma privada de enviar peticiones. La estandarización responde preguntas simples pero críticas:

• ¿Cómo nombramos un recurso? (URL)
• ¿Cómo pide un cliente y cómo lo recibe? (HTTP)
• ¿Cómo se estructura el resultado para que pueda mostrarse y enlazarse? (HTML)

Cuando esas reglas son consistentes, la Web se vuelve “mezclar y combinar”: cualquier navegador compatible + cualquier servidor compatible = funciona.

Los estándares evolucionan—sin romper la Web

Lo impresionante es que los estándares pueden mejorar mientras los fundamentos siguen siendo reconocibles. HTTP ha pasado de versiones tempranas a HTTP/1.1, luego a HTTP/2 y HTTP/3, añadiendo mejor rendimiento y eficiencia. Pero la idea central sigue siendo la misma: un cliente solicita una URL, un servidor responde con un código de estado, cabeceras y un cuerpo.

HTML también ha crecido—from documentos simples a una semántica más rica y medios integrados—mientras preserva el concepto básico de páginas e hipervínculos.

La compatibilidad hacia atrás es una característica, no un accidente

Gran parte de la perdurabilidad de la Web proviene de la fuerte preferencia por la compatibilidad hacia atrás. Los navegadores nuevos aún intentan renderizar páginas antiguas; los servidores nuevos aún entienden peticiones HTTP antiguas. Eso significa que contenido y enlaces pueden perdurar años—a menudo décadas.

Diseñar para la longevidad

Si quieres que tu sitio o app envejezca bien, apóyate en un diseño basado en estándares: usa URLs reales para estados compartibles, sigue las convenciones HTTP para caché y códigos de estado, y escribe HTML válido antes de añadir capas extra. Los estándares no son restrictivos—son lo que mantiene tu trabajo portátil, fiable y preparado para el futuro.

Conceptos erróneos comunes (y soluciones rápidas)

Aunque uses la web a diario, algunos términos se confunden tanto que pueden entorpecer la resolución de problemas, la planificación o conversaciones simples. Aquí tienes errores frecuentes y la forma más rápida de corregirlos.

“La Internet” vs “la Web”

Concepto erróneo: La Internet y la World Wide Web son lo mismo.

Solución rápida: La Internet es la red global (cables, routers, conexiones). La Web es un servicio que funciona encima, construido de URLs, HTTP y HTML.

URL vs dominio (y por qué importan las partes extra)

Concepto erróneo: “Mi URL es example.com.”

Solución rápida: example.com es un dominio. Una URL incluye detalles como la ruta y la consulta que cambian la respuesta del servidor, por ejemplo:

• https://example.com/pricing (una ruta específica)
• https://example.com/search?q=shoes (ruta más consulta)

Esas partes extra pueden cambiar lo que el servidor devuelve.

HTML vs HTTP

Concepto erróneo: HTML y HTTP son intercambiables.

Solución rápida: HTTP es la “conversación de entrega” (petición y respuesta). HTML es uno de los “paquetes” que se entregan—a menudo el que describe una página y sus enlaces. HTTP también puede entregar JSON, imágenes, PDFs o vídeo.

Códigos de estado y redirecciones

Concepto erróneo: Cualquier error significa “el sitio está caído” y las redirecciones siempre son malas.

Solución rápida: Los códigos de estado son señales:

• 404: el servidor es alcanzable, pero ese recurso no se encuentra
• 500: el servidor tuvo un problema interno
• 301/302: te están redirigiendo (a menudo normal después de mover una página)

“Una URL siempre apunta a una página”

Concepto erróneo: Toda URL debería abrir una página legible para humanos.

Solución rápida: Una URL puede apuntar a datos (/api/orders), a un archivo (/report.pdf) o a un endpoint de acción para un formulario.

HTTPS = ¿confiable?

Concepto erróneo: Si tiene HTTPS, el sitio es seguro y honesto.

Solución rápida: HTTPS cifra la conexión y ayuda a confirmar que te conectas al dominio correcto—pero no garantiza que el negocio sea legítimo. Debes evaluar:

• la reputación de la fuente
• si la URL es la esperada
• qué te piden descargar o enviar

Conclusiones clave y dónde profundizar

La idea central de Tim Berners-Lee fue sorprendentemente pequeña: conectar documentos (y luego aplicaciones) usando un esquema de direcciones compartido, una forma compartida de solicitar datos y un formato compartido para mostrarlos.

Los tres bloques en un minuto

URL es la dirección. Te dice qué quieres y dónde vive (y a menudo cómo llegar).

HTTP es la conversación. Es el conjunto de reglas que un navegador y un servidor usan para pedir algo y responder (códigos de estado, cabeceras, caché y más).

HTML es el formato de página. Es lo que un navegador puede leer para renderizar contenido—y, crucialmente, donde los enlaces conectan un recurso con otro.

Un modelo mental reutilizable

Piensa en la web como un bucle sencillo de tres pasos:

1. Nombrarlo (URL) — “Ve a esta dirección.”
2. Pedirlo (HTTP) — “Dame este recurso.”
3. Mostrarlo y enlazar adelante (HTML) — “Esto es lo que significa, y aquí están los siguientes caminos.”

Con ese bucle en mente, los detalles modernos (cookies, APIs, aplicaciones de una sola página, CDNs) son más fáciles de entender: suelen ser refinamientos en nombrar, pedir o renderizar.

Lecturas recomendadas

Si quieres profundizar sin volverte muy técnico:

• HTTP en palabras sencillas: /blog/how-http-works
• URLs desmitificadas: /blog/what-is-a-url
• Esenciales de HTML y enlaces: /blog/html-basics

Entender estos conceptos básicos da resultados rápidos: serás mejor evaluando herramientas web (“¿Esto depende de URLs y HTTP estándar?”), comunicándote con desarrolladores y resolviendo problemas cotidianos como enlaces rotos, sorpresas por caché o errores “404 vs 500”.