🔗 Entendiendo las URLs: Conceptos Básicos Basados en el Estándar RFC

Hoy quiero hablarles de algo que todos usamos a diario, pero que muy pocos entienden a fondo: las URLs.

Me resulta curioso, que muchas personas que ya tienen experiencia en desarrollando web, a veces desconozcan la base técnica sobre la que está construido el concepto de una URL.

Saben que una URL apunta a una página o a un recurso, sí... pero ¿qué significa cada parte?, ¿por qué algunas llevan puerto y otras no? pues hoy vamos a explorar parte de la documentación técnica contenida en el estándar RFC 3986.

Este artículo te explica paso a paso, con ejemplos claros y lenguaje simple pero sin perder el rigor técnico cómo está estructurada una URL según el estándar oficial de Internet.

Así que si quieres mejorar tu comprensión de la web desde sus cimientos, lee hasta el final, porque este es un tema mucho más interesante de lo que parece.

---

QUÉ ES UNA URL

Empecemos por lo básico.

Una URL (Uniform Resource Locator) es una forma estandarizada de identificar y localizar recursos en la red: páginas, archivos, imágenes o servicios.

Según el estándar RFC 3986, una URL es un tipo específico de URI (Identificador Uniforme de Recurso). La diferencia es que una URL no solo identifica un recurso, sino que también indica cómo acceder a él, normalmente a través de un protocolo.

Imagina que una URL es como una dirección postal digital:

• el protocolo te dice cómo llegar,
• el servidor te dice dónde está,
• y la ruta te indica a qué parte específica quieres acceder.

Un ejemplo clásico sería:

👉🏾 https://www.ejemplo.com/ruta/archivo.html?parametro=valor#seccion

Ahora, veamos cómo se compone internamente.

---

ESTRUCTURA GENERAL DE UNA URL

El RFC 3986 define la sintaxis general de un URI —y por extensión de una URL— de forma jerárquica.

La estructura base es esta: scheme:[//authority]path[?query][#fragment]

Cada componente cumple una función específica:

1. Scheme → define el protocolo.
2. Authority → indica el servidor o host.
3. Path → especifica la ruta dentro del servidor.
4. Query → contiene los parámetros de consulta.
5. Fragment → apunta a una parte específica del recurso.

No todas las URLs usan todos los componentes.

Por ejemplo,

• mailto:[e-mail] solo tiene el scheme y el path.
• tel:[phone] solo tiene el scheme y el path.

En ninguno de los ejemplos anteriores se utilizan los componentes de autoridad, ruta, consulta ni fragmento.

---

SCHEME (ESQUEMA)

El scheme es la primera parte de la URL. Este define cómo acceder al recurso, y siempre termina con dos puntos (:).

Algunos ejemplos comunes:

• http: → sitios sin cifrado.
• https: → sitios seguros (con TLS/SSL).
• ftp: → transferencia de archivos.
• mailto: → direcciones de correo electrónico.
• tel: → direcciones de teléfono.
• ssh: → conexiones seguras a servidores SSH

El RFC establece que el scheme debe comenzar con una letra y puede incluir dígitos, más (+), punto (.) o guion (-).

👉🏾 En https://www.ejemplo.com, el scheme es https.

---

AUTHORITY (AUTORIDAD)

Después del scheme, viene la authority, que empieza con //. Esta parte le dice al navegador a qué servidor conectarse.

La autoridad puede incluir tres sub componentes:

• Userinfo → usuario y contraseña (por seguridad, a día de hoy casi no se usa).
• Host → el dominio o dirección IP.
• Port → el puerto, si no, se usa el predeterminado.

Ejemplo: 👉🏾 https://[e-mail]:443

• usuario@ → userinfo
• www.ejemplo.com → host
• :443 → puerto

Si el puerto no se indica, se asume el estándar del protocolo (por ejemplo, 80 para HTTP, 443 para HTTPS).

---

PATH (RUTA)

El path indica la ubicación exacta del recurso dentro del servidor. Empieza con / y puede tener varios niveles.

Ejemplo: 👉🏾 /ruta/subruta/archivo.html

Si el path está vacío, el navegador asume que debe cargar el recurso raíz (/).

El RFC también define qué caracteres son válidos.

Los caracteres especiales —como espacios— deben codificarse con %.

Por ejemplo: un espacio se representa como %20.

---

QUERY (CONSULTA)

La query empieza con ? y permite enviar información adicional al servidor. Sigue el formato clave=valor, y si hay varios parámetros, se separan con &.

Ejemplo: 👉🏾 https://www.ejemplo.com/buscar?termino=palabra&pagina=2

En este caso, termino y pagina son parámetros que el servidor usa para generar una respuesta específica como en una búsqueda o una API REST.

---

FRAGMENT (FRAGMENTO)

El fragmento empieza con # y apunta a una parte específica del recurso, como una sección dentro de una página HTML.

Ejemplo: 👉🏾 https://www.ejemplo.com/pagina.html#seccion3

👀 Importante: el fragmento no se envía al servidor, lo interpreta el navegador. Sirve, por ejemplo, para desplazarte automáticamente a un ancla o una parte específica del contenido.

---

CONSIDERACIONES CLAVE

Antes de cerrar, repasemos algunos detalles importantes definidos por el RFC:

• Codificación: los caracteres no válidos se codifican con % y dos dígitos hexadecimales.
• URLs relativas: pueden omitir el scheme y el host, tomando el contexto actual.
• Normalización: los navegadores pueden ajustar mayúsculas, puntos o rutas internas automáticamente.
• Seguridad: evita incluir datos sensibles en la URL, ya que pueden quedar registrados en logs o historiales.

---

CONCLUSIÓN

Y eso es, en esencia, cómo está compuesta una URL según el estándar RFC 3986.

Detrás de cada dirección que escribes en el navegador hay una estructura cuidadosamente diseñada que permite que la web funcione de forma ordenada, segura y predecible.

Si estás construyendo APIs, desarrollando front-ends o simplemente quieres entender cómo viaja la información por Internet, dominar este tema te da una base sólida para todo lo que viene después.

💬 Cuéntame en los comentarios:

¿Ya conocías todas las partes de una URL y su función?