DEV Community: Sanders Gutérrez

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

Sanders Gutérrez — Tue, 11 Nov 2025 07:38:38 +0000

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:

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

No todas las URLs usan todos los componentes.

Por ejemplo,

mailto:usuario@ejemplo.com solo tiene el scheme y el path.
tel:+1-212-555-1234 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://usuario@www.ejemplo.com: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?

🧩 Cómo solucionar problemas de integridad en dependencias de Node.js

Sanders Gutérrez — Mon, 13 Oct 2025 07:40:30 +0000

💡 Introducción: el día que NPM decide no cooperar

Estás instalando tus dependencias como siempre. Escribes npm install, presionas Enter, esperas unos segundos (o una eternidad 😴)... y de pronto, aparece el mensaje:

npm ERR! code EINTEGRITY
npm ERR! sha512-abc123... integrity checksum failed

Respiras hondo... Vuelves a intentarlo... Nada... El mismo error... 😤😡🤬

Este tipo de problema ---tan frustrante como misterioso--- ocurre cuando el hash de integridad de un paquete descargado no coincide con el esperado. En otras palabras: NPM detecta que el archivo no es exactamente el mismo que debería ser según el registro oficial.

Aunque muchas guías recomiendan borrar node_modules o limpiar la
caché, existe un método no sé si más rápido, no sé si más limpio, pero definitivamente más preciso:
corregir el hash de integridad manualmente en el package-lock.json.

En este artículo, aprenderás a hacerlo paso a paso, con ejemplos reales y también te lo explico en video aquí "Cómo solucionar problemas de integridad en dependencias de Node.js".

🔍 Paso 1: Identificar la dependencia que está fallando

El primer paso es leer con atención el mensaje de error.
NPM te dirá qué dependencia está causando el problema. Por ejemplo:

npm ERR! EINTEGRITY: sha512 checksum failed for follow-redirects

Esto significa que el paquete follow-redirects descargado no coincide con el que el lockfile esperaba.

También suele aparecer una línea que indica dónde encontrar el registro completo del error:

See the log for details: /ruta/al/npm-debug.log

Ese archivo (npm-debug.log) contiene el detalle completo, pero en
general con el nombre del paquete basta para actuar.

🧭 Paso 2: Localizar el paquete en el `package-lock.json`

Una vez identificado el nombre, abrimos el archivo package-lock.json.

Este archivo guarda información exacta sobre las versiones y hashes de integridad de cada dependencia.

Busca el nombre del paquete, por ejemplo:

"follow-redirects": {
  "version": "1.15.0",
  "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.0.tgz",
  "integrity": "sha512-XYZ123..."
}

El campo "integrity" es el que NPM compara al instalar.

Si ese valor no coincide con el que el registro oficial tiene, el
proceso falla.

⚙️ Paso 3: Obtener el hash de integridad correcto

Ahora que sabemos cuál es el paquete problemático, debemos obtener el hash correcto directamente desde el registro oficial de NPM.

Ejecuta:

npm show follow-redirects

El comando mostrará información como esta:

dist:
  integrity: sha512-AbCdEfGh...

El valor que ves ahí es el hash oficial, calculado a partir del
paquete original en el registro.

Esa es la cadena que debe reemplazar al valor incorrecto del
package-lock.json.

✏️ Paso 4: Actualizar el hash manualmente

Con el hash correcto copiado, regresa al package-lock.json y reemplaza el valor anterior por el nuevo.

En algunos proyectos, la misma dependencia puede aparecer varias veces (por ejemplo, como dependencia de otro paquete).

Por eso, te recomiendo buscar todas las apariciones del nombre del paquete y reemplazar el campo "integrity" en cada una.

Ejemplo de corrección:

"node_modules/follow-redirects": {
  "version": "1.15.0",
  "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.0.tgz",
  "integrity": "sha512-AbCdEfGh..."  ← nuevo hash
}

Guarda el archivo.
No es necesario borrar node_modules todavía.

🔁 Paso 5: Reinstalar dependencias

Con el package-lock.json corregido, ejecuta nuevamente:

npm install

NPM descargará los paquetes y verificará los hashes actualizados.
Si todo fue reemplazado correctamente, el error de integridad
desaparecerá para esa dependencia.

💬 En el video te muestro claramente cómo, tras corregir el hash de follow-redirects, el error deja de aparecer.

🧩 Paso 6: Aplicar el mismo método a otras dependencias

En algunos casos, el error se repite con otros paquetes.
Por ejemplo, la librería semver (una dependencia muy usada para el control de versiones).

El procedimiento es el mismo:

npm show semver

Copia el valor de dist.integrity, busca todas las apariciones de
semver en el package-lock.json y reemplázalo.
Luego vuelve a ejecutar npm install.

Si la dependencia es indirecta (es decir, pertenece a otra librería), puede aparecer varias veces dentro del lockfile.
Asegúrate de reemplazar todas las coincidencias.

🧼 Paso 7: Verificar que todo funciona correctamente

Una vez actualizados los hashes, ejecuta de nuevo:

npm install

Si el error original ya no aparece, ¡felicitaciones! 🎉
Has corregido manualmente un problema de integridad en tus dependencias.

Si aún aparece un error distinto, repite el proceso para ese nuevo
paquete.

A veces, varios paquetes presentan el mismo tipo de inconsistencia si se descargaron bajo una conexión inestable o si el lockfile fue modificado manualmente.

🧠 Entendiendo por qué ocurre este error

El error EINTEGRITY aparece cuando el checksum (hash SHA512)
calculado a partir del paquete descargado no coincide con el hash
registrado en el lockfile.

Esto puede deberse a:

Descargas interrumpidas o corruptas.
Caché dañada de NPM.
Lockfile desactualizado tras una actualización manual del package.json.
Inconsistencias entre versiones de NPM en distintos entornos (local vs CI/CD).
Mirrors de registro (proxies o caches) que devuelven paquetes alterados. (OJO - Ten mucho cuidado con esto 👀🧐🕵🏾).

Corregir manualmente el hash es una solución inmediata y precisa, pero también conviene revisar la causa raíz para evitar que se repita.

⚡ Alternativas si el error persiste

Si luego de corregir los hashes manualmente los errores continúan,
prueba lo siguiente:

Verificar y limpiar caché de NPM

npm cache verifylternativas si el error persiste
npm cache clean --force

Eliminar node_modules y el lockfile

rm -rf node_modules
rm -f package-lock.json
npm install

Usar versiones compatibles de NPM
```
npm install -g npm@latest
```
Evitar conflictos entre gestores

No mezcles npm y yarn en el mismo proyecto.

Mantén un solo archivo de lock (package-lock.json o yarn.lock, nunca ambos).

🧩 Ejemplo completo resumido

1️⃣ Identificar paquete problemático - npm install
2️⃣ Buscar el hash actual - Editar package-lock.json
3️⃣ Obtener hash correcto - npm show <paquete>
4️⃣ Actualizar hash manualmente - Editar package-lock.json
5️⃣ Reinstalar dependencias - npm install
6️⃣ Verificar resultados - Revisión en consola

🧱 Buenas prácticas para prevenir estos errores

Usa versiones estables de Node y NPM.
Documenta en tu proyecto las versiones recomendadas con .nvmrc o "engines" en el package.json.
Evita editar manualmente el lockfile, salvo para este tipo de corrección puntual.
Usa npm ci en entornos de integración continua (CI/CD) para instalaciones limpias y reproducibles.
Controla las actualizaciones automáticas: si tu editor o entorno actualiza dependencias sin sincronizar el lockfile, podrías romper la integridad.

🏁 Conclusión

Los errores de integridad en Node.js pueden parecer complejos, pero en realidad son una medida de seguridad que protege tu proyecto frente a paquetes corruptos o manipulados.

En lugar de eliminar todo el entorno, puedes resolver el problema
editando directamente el package-lock.json con el hash correcto obtenido de npm show. Así evitas reinstalaciones innecesarias y conservas la estabilidad de tu proyecto.

🚀 En resumen

Identifica el paquete con error.
Obtén el hash correcto desde npm show.
Reemplázalo en tu lockfile.
Reinstala y verifica.
Evita mezclar gestores y mantén tu entorno limpio.

Sencillo, directo y eficaz. 💪🏾

🎥 CTA --- Aprende más en mi canal

Si te gustó esta explicación, te invito a visitar mi canal de YouTube, donde explico paso a paso este proceso en video y comparto tutoriales sobre Node.js, NPM, y desarrollo web moderno.

👉🏾 Visita el canal aquí
(https://www.youtube.com/@untalsanders)