html - una - URL absolutas vs relativas

url relativos y absolutos (12)

¿Debo usar URL absolutas o relativas?

Si por URL absolutas quieres decir URL incluyendo el esquema (ej. Http / https) y el nombre del servidor (ej. Tudominio.com) nunca hagas eso (para recursos locales) porque será terrible de mantener y depurar.

Supongamos que ha utilizado la URL absoluta en todas partes de su código, como <img src="http://yourdomain.com/images/example.png"> . Ahora, ¿qué pasará cuando vayas a:

cambiar a otro esquema (por ejemplo, http -> https)
cambiar los nombres de dominio (test.yourdomain.com -> tudominio.com)

En el primer ejemplo, lo que sucederá es que recibirás advertencias sobre la solicitud de contenido inseguro en la página. Porque todas sus URL están codificadas para usar http (: //yourdomain.com/images/example.png). Y cuando ejecuta sus páginas en http, el navegador espera que todos los recursos se carguen en https para evitar la filtración de información.

En el segundo ejemplo, al poner su sitio en funcionamiento desde el entorno de prueba, significa que todos los recursos aún apuntan a su dominio de prueba en lugar de su dominio en vivo.

Entonces, para responder a su pregunta sobre si usar URLs absolutas o relativas: siempre use URL relativas (para recursos locales).

¿Cuál es la diferencia entre las diferentes URL?

Primero, echemos un vistazo a las diferentes URL que podemos usar:

http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png

¿A qué recursos intentan acceder estas URL en el servidor?

En los ejemplos a continuación, supongo que el sitio web se ejecuta desde la siguiente ubicación en el servidor /var/www/mywebsite .

http://yourdomain.com/images/example.png

La URL anterior (absoluta) intenta acceder al recurso /var/www/website/images/example.png . Este tipo de URL es algo que siempre desearía evitar para solicitar recursos de su propio sitio web por el motivo descrito anteriormente. Sin embargo, tiene su lugar. Por ejemplo, si tiene un sitio web http://yourdomain.com y desea solicitar un recurso de un dominio externo en lugar de http, debe usar esto. Por ejemplo, https://externalsite.com/path/to/image.png .

//yourdomain.com/images/example.png

Esta URL se basa en el esquema actual utilizado y casi siempre se debe usar cuando se incluyen recursos externos (imágenes, javascripts, etc.).

Lo que hace este tipo de URL es usar el esquema actual de la página en la que se encuentra. Esto significa que se encuentra en la página http://yourdomain.com y en esa página hay una etiqueta de imagen <img src="//yourdomain.com/images/example.png"> la URL de la imagen se resolvería en http://yourdomain.com/images/example.png .
Cuando hubiera estado en la página http**s**://yourdomain.com y en esa página haya una etiqueta de imagen <img src="//yourdomain.com/images/example.png"> la URL de la la imagen se resolvería en https://yourdomain.com/images/example.png .

Esto evita cargar recursos sobre https cuando no es necesario y automáticamente asegura que el recurso se solicita sobre https cuando es necesario.

La URL anterior se resuelve de la misma manera en el lado del servidor que la URL anterior:

La URL anterior (absoluta) intenta acceder al recurso /var/www/website/images/example.png .

/images/example.png

Para los recursos locales, esta es la forma preferida de hacer referencia a ellos. Esta es una URL relativa basada en el documento raíz ( /var/www/mywebsite ) de su sitio web. Esto significa que cuando tienes <img src="/images/example.png"> siempre se resolverá en /var/www/mywebsite/images/example.png .

Si en algún momento decide cambiar de dominio, seguirá funcionando porque es relativo.

images/example.png

Esta es también una URL relativa aunque un poco diferente a la anterior. Esta URL es relativa a la ruta actual. Lo que esto significa es que se resolverá en diferentes rutas dependiendo de dónde se encuentre en el sitio.

Por ejemplo, cuando se encuentra en la página http://yourdomain.com y utiliza <img src="images/example.png"> se resolvería en el servidor a /var/www/mywebsite/images/example.png como esperado, sin embargo, cuando se encuentre en la página http://yourdomain.com/some/path y utilice exactamente la misma etiqueta de imagen, de repente se resolverá en /var/www/mywebsite/some/path/images/example.png .

Cuándo usar qué?

Al solicitar recursos externos, lo más probable es que desee utilizar una URL relacionada con el esquema (a menos que desee forzar un esquema diferente) y cuando trate con recursos locales, quiere usar URL relativas basadas en la raíz del documento.

Un documento de ejemplo:

<!DOCTYPE html> <html> <head> <title>Example</title> <link href=''//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700'' rel=''stylesheet'' type=''text/css''> <link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style> </head> <body> <img src="/images/some/localimage.png" alt=""> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script> </body> </html>

Algunos (un poco) duplicados

Me gustaría saber las diferencias entre estos dos tipos de URL: URL relativas (para imágenes, archivos CSS, archivos JS, etc.) y URL absolutas.

Además, ¿cuál es mejor usar?

Digamos que tiene un sitio www.yourserver.com. En el directorio raíz para documentos web tiene una subdirección de imágenes y en ella tiene myimage.jpg.

Una URL absoluta define la ubicación exacta del documento, por ejemplo:

http://www.yourserver.com/images/myimage.jpg

Una URL relativa define la ubicación relativa al directorio actual , por ejemplo, dado que se encuentra en el directorio web raíz en el que se encuentra su imagen:

images/myimage.jpg

(relativo a ese directorio raíz)

Siempre debe usar URL relativos siempre que sea posible. Si mueve el sitio a www.anotherserver.com, deberá actualizar todas las URL absolutas que apuntan a www.yourserver.com, las relativas seguirán funcionando tal cual.

En general, se considera una mejor práctica utilizar URL relativas, de modo que su sitio web no se vincule con la URL base de donde se implementa actualmente. Por ejemplo, podrá trabajar en localhost, así como en su dominio público, sin modificaciones.

En la mayoría de los casos, las URL relativas son el camino a seguir, son portátiles por naturaleza, lo que significa que si quisieras levantar tu sitio y colocarlo en otro lugar, funcionaría instantáneamente, reduciendo posiblemente horas de depuración.

Hay un artículo bastante bueno sobre URL absolutas en comparación con las relativas , échale un vistazo.

En realidad, hay tres tipos que deben discutirse explícitamente. En la práctica, aunque las URL se han resumido para ser manejadas en un nivel inferior, llegaría a decir que los desarrolladores podrían pasar toda su vida sin escribir una sola URL a mano.

Absoluto

Las URL absolutas vinculan tu código con el protocolo y el dominio. Esto se puede superar con URL dinámicas.

<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>

Pros absoluta:

Control : el subdominio y el protocolo se pueden controlar. Las personas que ingresan a través de un subdominio oscuro se canalizarán al subdominio adecuado. Puede ir y venir entre seguro y no seguro, según corresponda.
Configurable : los desarrolladores aman las cosas para ser absoluto. Puede diseñar algoritmos puros al usar URL absolutas. Las URL pueden configurarse para que una URL se pueda actualizar en todo el sitio con un solo cambio en un solo archivo de configuración.
Clarividencia : puede buscar a las personas que roban su sitio o tal vez recoger algunos enlaces externos adicionales.

Raíz Relativa

Las URL relativas de raíz vinculan su código a la url base. Esto se puede superar con URL dinámicas y / o etiquetas base .

<a href=“/index.php?q=”>.example.com/index.php?q=</a>

Raíz parientes positivos:

Configurable : la etiqueta base los hace relativos a cualquier raíz que elijas, facilitando el cambio de dominios y la implementación de plantillas.

Relativo

Las URL relativas vinculan su código a la estructura del directorio. No hay forma de superar esto. Las URL relativas solo son útiles en los sistemas de archivos para el desplazamiento de directorios o como un acceso directo para una tarea manual.

<a href=“index.php?q=”>index.php?q=</a> <link src=“../.././../css/default.css” />

Desventajas relativas:

CONFUSO - ¿Cuántos puntos es eso? cuantas carpetas es eso? ¿Dónde está el archivo? ¿Por qué no está funcionando?
MANTENIMIENTO : si un archivo se mueve accidentalmente, los recursos dejan de cargarse, los enlaces envían al usuario a las páginas incorrectas, los datos del formulario pueden enviarse a la página incorrecta. Si un archivo NECESITA ser movido, todos los recursos que van a dejar de cargarse y todos los enlaces que serán incorrectos deben actualizarse.
NO ESCALA : cuando las páginas web se vuelven más complejas y las vistas se vuelven a utilizar en varias páginas, los enlaces relativos estarán relacionados con el archivo en el que se incluyeron. Si tiene un fragmento de navegación HTML que va a aparecer en cada página, entonces relativo será relativo a muchos lugares diferentes. Lo primero que las personas se dan cuenta cuando comienzan a crear una plantilla es que necesitan una forma de administrar las URL.
COMPUTADO - Son implementados por su navegador (con suerte según RFC). Ver el capítulo 5 en RFC3986 .
¡OOPS! - Errores o errores tipográficos pueden provocar trampas de araña.

La evolución de las rutas

Los desarrolladores han dejado de escribir URL en el sentido que se analiza aquí. Todas las solicitudes son para el archivo de índice de un sitio web y contienen una cadena de consulta, también conocida como ruta. La ruta puede considerarse como una mini URL que le dice a su aplicación el contenido que se generará.

<a href="<?=Route::url(''named_url'', array(''first'' => ''my'', ''last'' => ''whacky''))?>"> http://dev.example.com/index.php/my:whacky:url </a>

Pros de rutas:

Todas las ventajas de las URL absolutas.
Uso de cualquier personaje en URL.
Más control (Bueno para SEO).
Capacidad de generar URLs algorítmicamente. Esto permite que las URL sean configurables. Alterar la URL es un cambio único en un solo archivo.
No es necesario que 404 no funde. Las rutas de retorno pueden mostrar un mapa del sitio o una página de error.
Seguridad conveniente de acceso indirecto a los archivos de la aplicación. Las declaraciones de guardia pueden asegurar que todo el mundo llegue a través de los canales apropiados.
Practicidad en el enfoque MVC.

Mi toma

La mayoría de las personas hará uso de las tres formas en sus proyectos de una manera u otra. La clave es comprenderlos y elegir el más adecuado para la tarea.

Para cada sistema que admite la resolución URI relativa, los URI relativos y absolutos tienen el mismo objetivo: hacer referencia. Y se pueden usar indistintamente. Entonces puedes decidir en cada caso de manera diferente. Técnicamente, proporcionan la misma referencia.

Para ser precisos, con cada URI relativo ya existe un URI absoluto. Y ese es el URI de base contra el que se resuelve el URI relativo. Por lo tanto, un URI relativo es en realidad una función además de los URI absolutos.

Y esa también es la razón por la que con los URI relativos puede hacer más que con un URI absoluto solo: esto es especialmente importante para los sitios web estáticos que de otro modo no podrían ser tan flexibles de mantener en comparación con los URI absolutos.

Estos efectos positivos de la resolución relativa del URI también se pueden aprovechar para el desarrollo dinámico de aplicaciones web. Los URIs de inflexibilidad absoluta también son más fáciles de manejar, en un entorno dinámico, por lo que para algunos desarrolladores que no están seguros acerca de la resolución de URI y cómo implementarlo y administrarlo correctamente (aunque no siempre es fácil) a menudo optan por usar URI en una parte dinámica de un sitio web, ya que pueden introducir otras características dinámicas (por ejemplo, la variable de configuración que contiene el prefijo URI) para evitar la inflexibilidad.

Entonces, ¿cuál es el beneficio en el uso de URI absolutos? Técnicamente no lo hay, pero diría uno: los URI relativos son más complejos porque deben resolverse contra el denominado URI de base absoluta. Incluso la resolución está estrictamente definida desde hace años, puede ejecutar a un cliente que tiene un error en la resolución de URI. Como los URI absolutos no necesitan ninguna resolución, el uso de URI absolutos no presenta ningún riesgo de comportamiento deficiente del cliente con una resolución de URI relativa. Entonces, ¿qué tan alto es ese riesgo en realidad? Bueno, es muy raro. Solo sé sobre un navegador de Internet que tuvo un problema con la resolución relativa de URI. Y eso no fue en general sino solo en un caso muy (oscuro).

Al lado del cliente HTTP (navegador), quizás sea más complejo para un autor de documentos de hipertexto o código. Aquí, el URI absoluto tiene el beneficio de que es más fácil de probar, ya que puede ingresarlo tal como está en la barra de direcciones de su navegador. Sin embargo, si no se trata solo de su trabajo de una hora, lo más habitual es que le resulte más útil comprender realmente el manejo de URI absoluto y relativo para que pueda explotar los beneficios de los enlaces relativos.

Recomendaría encarecidamente URL relativas para señalar bits del mismo sitio a otros bits del mismo sitio.

No olvide que un cambio a HTTPS, incluso si está en el mismo sitio, va a necesitar una URL absoluta.

Si es para usar en su sitio web, es una buena práctica usar una URL relativa, como esta, si necesita mover el sitio web a otro nombre de dominio o simplemente depurar localmente, puede hacerlo.

Eche un vistazo a lo que está haciendo (ctrl + U en firefox):

<a href="/users/recent/90691"> // Link to an internal element

En algunos casos usan urls absolutas:

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

... pero esto es solo una mejor práctica para mejorar la velocidad. En tu caso, no parece que estés haciendo algo así, así que no me preocuparía.

Supongamos que estamos creando un subsitio cuyos archivos están en la carpeta http://site.ru/shop .

1. URL absoluta

Link to home page href="http://sites.ru/shop/" Link to the product page href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"

2. URL relativa

Link from home page to product page href="t-shirts/t-shirt-life-is-good/" Link from product page to home page href="../../"

Aunque la URL relativa parece más corta que la absoluta, pero las URL absolutas son más preferibles, ya que un enlace se puede usar sin modificaciones en cualquier página del sitio.

Casos intermedios

Hemos considerado dos casos extremos: URL "absolutamente" absolutas y "absolutamente" relativas. Pero todo es relativo en este mundo. Esto también se aplica a las URL. Cada vez que diga sobre URL absoluta, siempre debe especificar en relación a qué.

3. URL relativa al protocolo

Link to home page href="//sites.ru/shop/" Link to product page href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"

Google recomienda dicha URL. Ahora, sin embargo, generalmente se considera que http: // y https: // son sitios diferentes.

4. URL relativa a la raíz

Es decir, relativo a la carpeta raíz del dominio.

Link to home page href="/shop/" Link to product page href="/shop/t-shirts/t-shirt-life-is-good/"

Es una buena opción si todas las páginas están dentro del mismo dominio. Cuando mueve su sitio a otro dominio, no tiene que hacer un reemplazo masivo del nombre de dominio en las URL.

5. URL relativa a la base (relativa a la página de inicio)

La etiqueta <base> especifica la URL base, que se agrega automáticamente a todos los enlaces y anclas relativos. La etiqueta base no afecta a los enlaces absolutos. Como URL base especificaremos la página de inicio: <base href = "http://sites.ru/shop/">.

Link to home page href="" Link to product page href="t-shirts/t-shirt-life-is-good/"

Ahora puede mover su sitio no solo a ningún dominio, sino a cualquier subcarpeta. Solo tenga en cuenta que, aunque las URL parezcan relativas, de hecho son absolutas. Especialmente presta atención a los anclajes. Para navegar dentro de la página actual, tenemos que escribir href = "camisetas / t-shirt-life-is-good / # comments" not href = "# comments". Este último lanzará en la página de inicio.

Conclusión

Para los enlaces internos, uso URL relativas a la base (5). Para enlaces externos y boletines, uso URL absolutas (1).

Una URL que comienza con el esquema de URL y la parte específica del esquema ( http:// , https:// , ftp:// , etc.) es una URL absoluta.

Cualquier otra URL es una URL relativa y necesita una URL base de la que la URL relativa se resuelva (y, por lo tanto, dependa de) que sea la URL del recurso en el que se utiliza la referencia si no se declara lo contrario.

Eche un vistazo a RFC 2396 - Apéndice C para ver ejemplos de cómo resolver URL relativas.

Vea esto: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

Una url absoluta incluye las partes antes de la parte "ruta"; en otras palabras, incluye el esquema (el http en http://foo/bar/baz ) y el nombre de host (el foo en http://foo/bar/baz ) (y opcionalmente puerto, información de usuario y puerto).

Las URL relativas comienzan con un camino.

Las URL absolutas son, pues, absolutas: la ubicación del recurso se puede resolver mirando solo a la url misma. Una url relativa es, en cierto sentido, incompleta: para resolverla, necesita el esquema y el nombre de host, y estos se suelen tomar del contexto actual. Por ejemplo, en una página web en

http://myhost/mypath/myresource1.html

podrías poner un enlace así

<a href="pages/page1">click me</a>

En el atributo href del enlace, se usa una URL relativa, y si se hace clic en ella, debe resolverse para seguirla. En este caso, el contexto actual es

http://myhost/mypath/myresource1.html

por lo que el esquema, el nombre de host y la ruta de acceso principal de estos se toman y se anteponen a las pages/page1 , produciendo

http://myhost/mypath/pages/page1

Si el enlace hubiera sido:

<a href="/pages/page1">click me</a>

(observe el / aparece al comienzo de la url) entonces se habría resuelto como

http://myhost/pages/page1

porque el leading / indica la raíz del host.

En una aplicación web, aconsejaría utilizar URL relativas para todos los recursos que pertenecen a su aplicación. De esa manera, si cambia la ubicación de las páginas, todo continuará funcionando. Todos los recursos externos (pueden ser páginas completamente ajenas a la aplicación, pero también contenido estático que usted entregue a través de una red de entrega de contenido) siempre deben apuntarse usando urls absolutas: si no lo hace simplemente no hay forma de localizarlos, porque residir en un servidor diferente.

Voy a tener que estar en desacuerdo con la mayoría aquí.

Creo que el esquema relativo de URL está "bien" cuando quieres poner rápidamente en marcha algo y no pensar fuera de la caja, particularmente si tu proyecto es pequeño con pocos desarrolladores (o solo tú).

Sin embargo, una vez que comienzas a trabajar en sistemas grandes y grasosos en los que cambias dominios y protocolos todo el tiempo, creo que se necesita un enfoque más elegante.

Cuando comparas las URL absolutas y relativas en esencia, Absolute gana. ¿Por qué? Porque nunca se romperá. Nunca. Una URL absoluta es exactamente lo que dice que es. El problema es cuando tienes que MANTENER tus URL absolutas.

El enfoque débil para la vinculación absoluta de URL es realmente difícil de codificar toda la URL. No es una gran idea, y probablemente el culpable de por qué la gente los ve como peligrosos / malvados / molestos de mantener. Un mejor enfoque es escribir usted mismo un generador de URL fácil de usar. Estos son fáciles de escribir y pueden ser increíblemente potentes: detectan automáticamente su protocolo, son fáciles de configurar (literalmente configuran la URL una vez para toda la aplicación), etc., e inyectan su dominio por sí mismos. Lo bueno de eso: sigues codificando usando URL relativas, y en el tiempo de ejecución la aplicación inserta tus URL como absolutos completos sobre la marcha. Increíble.

Viendo que prácticamente todos los sitios modernos usan algún tipo de back-end dinámico, lo mejor para él es hacerlo de esa manera. Las URL absolutas hacen más que simplemente asegurarte dónde apuntan, también pueden mejorar el rendimiento de SEO.

Debo agregar que el argumento de que las URL absolutas cambiarán de algún modo el tiempo de carga de la página es un mito. Si su dominio pesa más de unos pocos bytes y está en un módem de acceso telefónico en la década de 1980, seguro. Pero eso ya no es el caso. https://.com/ tiene 25 bytes, mientras que el archivo "topbar-sprite.png" que utilizan para el área de navegación del sitio pesa más de 9+ kb. Eso significa que los datos URL adicionales son .2% de los datos cargados en comparación con el archivo sprite, y ese archivo ni siquiera se considera un gran golpe de rendimiento.

Es mucho más probable que esa imagen de fondo grande, no optimizada, de página completa disminuya los tiempos de carga.

Una publicación interesante sobre por qué las URL relativas no deberían usarse está aquí: http://yoast.com/relative-urls-issues/

Un problema que puede surgir con los familiares, por ejemplo, es que a veces las asignaciones de servidores (tenga en cuenta los grandes proyectos desordenados) no se alinean con los nombres de los archivos y el desarrollador puede suponer una URL relativa que simplemente no es cierto. Lo vi hoy en un proyecto en el que estoy y trajo una página entera.

O tal vez un desarrollador se olvidó de cambiar un puntero y, de repente, google indexó todo el entorno de prueba. Whoops: contenido duplicado (¡malo para SEO!).

Los absolutos pueden ser peligrosos, pero cuando se usan correctamente y de una manera que no puede romper su construcción , se demuestra que son más confiables. Mira el artículo anterior, que da un montón de razones por las cuales el generador de url Wordpress es súper increíble.