26 mar 2025·8 min
La Web de Tim Berners-Lee: URLs, HTTP, HTML y por qué importa
Aprende cómo Tim Berners-Lee combinó URLs, HTTP y HTML para formar la World Wide Web—y por qué estas ideas simples siguen impulsando apps modernas y APIs.
Aprende cómo Tim Berners-Lee combinó URLs, HTTP y HTML para formar la World Wide Web—y por qué estas ideas simples siguen impulsando apps modernas y APIs.
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.
En su núcleo, la Web se apoya en un trío práctico:
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 gente suele usar “Web” e “Internet” como si fuesen intercambiables, pero son diferentes:
El correo electrónico, los juegos en línea y muchas apps de chat usan la Internet sin ser “la Web” en sentido estricto.
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.
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.
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:
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.
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.
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):
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)La gente suele usar estas palabras indistintamente:
Para propósitos prácticos, pensar “URL = dirección” te llevará el 95% del camino.
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).
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.
Las peticiones HTTP incluyen un método, que es simplemente el tipo de acción que realizas.
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.
Cada respuesta incluye un código de estado—piénsalo como el resultado de la entrega.
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 (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”.
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.
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.
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”.
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.
Es fácil confundirlos, pero tienen trabajos distintos:
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.
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.
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).
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.
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.
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.
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.
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):
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.
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.
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:
Un recurso es cualquier cosa que la web puede identificar y entregar en una URL. Ejemplos comunes incluyen:
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.
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.
Un formulario HTML es un conjunto estructurado de campos (como cajas de texto, casillas y botones) más dos instrucciones clave:
action)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”.
A alto nivel:
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.
En el servidor, un programa recibe la petición HTTP, lee los valores enviados y decide qué hacer:
El servidor responde—a menudo con una nueva página HTML (“¡Gracias!”), un mensaje de error o una redirección a otra URL.
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.
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.
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.
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:
La mayoría de apps modernas hablan con APIs: URLs que devuelven datos—a menudo JSON—sobre HTTP.
Por ejemplo:
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.
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.
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:
Cuando esas reglas son consistentes, la Web se vuelve “mezclar y combinar”: cualquier navegador compatible + cualquier servidor compatible = funciona.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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 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.
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.
Piensa en la web como un bucle sencillo de tres pasos:
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.
Si quieres profundizar sin volverte muy técnico:
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”.
La Internet es la red global (routers, cables, enrutamiento IP) que conecta computadoras. La Web es un servicio que funciona encima de ella: recursos identificados por URLs, transferidos con HTTP y, a menudo, mostrados como HTML.
Muchas cosas usan la Internet sin ser “la Web”, como el correo electrónico, algunos juegos multijugador y muchos sistemas de chat.
Piensa en una URL como una dirección precisa para un recurso. Puede apuntar a una página HTML, una imagen, un PDF o un endpoint de una API.
Una URL típica incluye:
Un dominio (como example.com) es solo el nombre de un host. Una URL puede incluir mucho más detalle—como la ruta y la consulta—que cambian lo que realmente obtienes.
Por ejemplo:
https://example.com/pricinghttps://example.com/search?q=shoesEl fragmento (la parte después de #) lo maneja el navegador; no se envía al servidor en la petición HTTP.
Usos comunes:
#reviews)Si solo cambias el fragmento, a menudo no se desencadena una recarga completa de la página.
HTTP son las reglas para la conversación de petición y respuesta entre un cliente (navegador/app) y un servidor.
En la práctica:
Usa GET cuando estés recuperando algo (con intención de solo lectura), como cargar una página o obtener datos.
Usa POST cuando estés enviando datos para que se procesen, como crear una cuenta, publicar un comentario o iniciar un pago.
Un truco práctico: si la acción debe poder guardarse en favoritos/compartirse (por ejemplo, una búsqueda), suele ser mejor; si cambia el estado en el servidor, es lo habitual.
Los códigos de estado resumen el resultado de una petición:
Al depurar, un suele indicar una URL incorrecta o una página eliminada; un normalmente apunta a un fallo o error del lado servidor.
El navegador necesita una dirección IP para conectarse a un servidor. DNS es el sistema que traduce un nombre legible (como example.com) a una dirección IP.
Si un sitio a veces “no se resuelve”, el DNS es un sospechoso habitual—especialmente si falla en una red/dispositivo pero funciona en otro.
El caché es cuando tu navegador guarda copias de recursos descargados anteriormente para que las visitas repetidas carguen más rápido.
Implicaciones prácticas:
Los servidores controlan gran parte del comportamiento de caché mediante cabeceras HTTP (como la duración y la revalidación).
HTTPS cifra el tráfico y ayuda a asegurarse de que te conectas al dominio correcto, lo que protege logins, formularios y datos sensibles en tránsito.
No garantiza que el sitio sea honesto o confiable. Aún debes evaluar:
https) — cómo acceder a ellaexample.com) — qué servidor/products/shoes) — qué recurso?color=black) — parámetros extra#reviews) — una ubicación dentro de la página (lado cliente)