URLs absolutas vs relativas

¿Debo usar URLs absolutas o relativas?

Si por URLs absolutas se refiere a URLs que incluyen scheme (p. ej. http / https) y el nombre de host (p. ej. yourdomain.com) nunca hagas eso (para los recursos locales) porque será terrible mantener y depurar.

Digamos que has usado URL absoluta en todas partes de tu código como <img src="http://yourdomain.com/images/example.png">. Ahora lo que sucederá cuando usted va a:

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

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

En el segundo ejemplo, al poner su sitio en vivo desde el entorno de prueba, significaría todos los recursos siguen apuntando a tu dominio de prueba en lugar de a tu dominio activo.

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

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

Primero echemos un vistazo a cuáles son las URLs de diferencia que podemos usar:

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

¿Qué recursos intentan estas URL? ¿acceso en el servidor?

En los siguientes ejemplos asumo 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 (absoluta) anterior intenta acceder al recurso /var/www/website/images/example.png. Este tipo de URL es algo que siempre desea evitar para solicitar recursos de su propio sitio web por la razón descrita anteriormente. Sin embargo, tiene su lugar. Por ejemplo, si tiene un sitio web http://yourdomain.com y desea solicitar un recurso desde un dominio externo sobre http debe usar esto. Por ejemplo, https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

Esta URL es relativa basada en el esquema actual utilizado y casi siempre debe usarse cuando se incluyen recursos externos (imágenes, scripts de java, 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 estás 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 lo haría han estado en la página http**s**://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 https://yourdomain.com/images/example.png.

Esto evita cargar recursos a través de https cuando no es necesario y automáticamente se asegura de que el recurso se solicite a través de https cuando es necesario.

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

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

/images/example.png

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

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

images/example.png

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

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

¿Cuándo usar qué?

Al solicitar recursos externos, lo más probable es que desee usar una URL en relación con el esquema (a menos que desee forzar un esquema diferente) y cuando se trata de recursos locales, desea utilizar direcciones 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 (kinda) duplicados

• Forma segura de escribir URL que se transfieran entre entornos
• ¿cuál es la forma correcta de vincular la imagen en el sitio web?

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

foo://username:[email protected]:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ /   \________________/\_________/ \__/            \___/ \_/ \_________/ \_________/ \__/
 |           |               |       |                |    |       |           |       |
 |       userinfo         hostname  port              |    |       parameter query  fragment
 |    \_______________________________/ \_____________|____|____________/
scheme                  |                               | |  |
 |                authority                           |path|
 |                                                    |    |
 |            path                       interpretable as filename
 |   ___________|____________                              |
/ \ /                        \                             |
urn:example:animal:ferret:nose               interpretable as extension

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 port, userinfo y port).

Las url relativas comienzan con una ruta de acceso.

Las url absolutas son, bueno, absolutas: la ubicación del recurso se puede resolver mirando solo a la url en sí. Una url relativa está en un sentido incompleto: para resolverlo, necesita el esquema y el nombre de host, y estos generalmente se toman del contexto actual. Por ejemplo, en una página web en

http://myhost/mypath/myresource1.html

Podrías poner un enlace así{[18]]}

<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

Así que el esquema, el nombre de host y la ruta principal de estos se toman y se anteponen a pages/page1, rendimiento

http://myhost/mypath/pages/page1

Si el enlace hubiera sido:

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

(tenga en cuenta que / aparece al inicio de la url), entonces se habría resuelto como

http://myhost/pages/page1

Porque el encabezado / indica la raíz del host.

En una aplicación web, recomendaría usar 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 seguirá funcionando. Cualquier recurso externo (podría ser páginas completamente fuera de su aplicación, pero también el contenido estático que entrega a través de una red de entrega de contenido) siempre se debe apuntar al uso de url absolutas: si no lo hace, simplemente no hay manera de localizarlos, porque residen en un servidor diferente.

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, las URL absolutas son más preferibles, ya que un enlace se puede usar sin cambios en cualquier página del sitio.

Casos intermedios

Hemos considerado dos casos extremos: URLs "absolutamente" absolutas y "absolutamente" relativas. Pero todo es relativo en este mundo. Esto también se aplica a las URL. Cada vez que dices acerca de la URL absoluta, siempre debes 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, relativa 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 mueves tu sitio a otro dominio, usted no tiene que hacer un reemplazo masivo del nombre de dominio en las URLs.

5. Base-relative URL (home-page-relative)

La etiqueta especifica la URL base, que se agrega automáticamente a todos los enlaces y anclajes relativos. La etiqueta base no afecta a los enlaces absolutos. Como URL base especificaremos la página de inicio: .

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 cualquier dominio, sino a cualquier subcarpeta. Solo ten en cuenta que, aunque las URL parecen relativas, de hecho son absolutas. Preste especial atención a los anclajes. Para navegar dentro de la página actual tenemos que escribir href= "t-shirts/t-shirt-life-is-good / #comments" no href="#comments". Este último se lanzará en la página de inicio.

Conclusión

Para enlaces internos utilizo URLs relativas a la base (5). Para enlaces externos y newsletters utilizo URLs absolutas (1).

Hay realmente tres tipos que deben ser discutidos explícitamente. En la práctica, aunque las URL se han abstraído para ser manejadas en un nivel inferior y yo iría tan lejos como para decir que los desarrolladores podrían pasar por toda su vida sin escribir una sola URL a mano.

Absoluto

Las URL absolutas vinculan su código al protocolo y al dominio. Esto se puede superar con URLs dinámicas.

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

Pros absolutos:

1. Control - La el subdominio y el protocolo se pueden controlar. Las personas que entran a través de un subdominio oscuro serán canalizadas al subdominio adecuado. Puede saltar de un lado a otro entre seguro y no seguro, según corresponda.

2. Configurable - A los desarrolladores les encanta que las cosas sean absolutas. Puede diseñar algoritmos nítidos al usar URL absolutas. Las URL se pueden configurar para que una URL se pueda actualizar en todo el sitio con un solo cambio en una sola configuración file.

3. Clarividencia - Usted puede buscar a las personas que raspan su sitio o tal vez recoger algunos enlaces externos adicionales.

Raíz Relativa

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

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

Pros:

1. Configurable - La etiqueta base los hace relativos a cualquier raíz que elija dominios e implementación de plantillas fácil.

Relativo

Las URL relativas vinculan su código a la estructura de directorios. No hay manera de superar esto. Las URL relativas solo son útiles en sistemas de archivos para atravesar directorios o como atajo para una tarea de poca importancia.

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

Contras relativas:

1. CONFUSO - ¿cuántos puntos es eso? ¿cuántas carpetas son? Dónde está el archivo? ¿Por qué no lo es? ¿trabajando?

2. MAINTENANCE - Si un archivo se mueve accidentalmente los recursos dejan de cargar, 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 salir de la carga y todos los enlaces que van a ser incorrectos deben ser actualizados.

3. NO ESCALA : Cuando las páginas web se vuelven más complejas y las vistas comienzan a reutilizarse en varias páginas, los enlaces serán relativos al archivo en el que se incluyeron. Si tiene un fragmento de navegación de HTML que va a estar 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.

4. COMPUTED - Son implementados por su navegador (esperemos que de acuerdo con RFC). Véase el capítulo 5 en RFC3986 .

5. OOPS! - Los errores o errores tipográficos pueden resultar en trampas de araña.

La Evolución de las Rutas

Los desarrolladores han dejado de escribir URLs en el sentido que se discute aquí. Todas las solicitudes son para el archivo de índice de un sitio web y contienen una cadena de consulta, también conocida como una ruta. La ruta se puede pensar 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:

1. Todos los ventajas de las urls absolutas.
2. Uso de cualquier carácter en URL.
3. Más control (Bueno para SEO).
4. Capacidad para generar URL algorítmicamente. Esto permite que las URL sean configurables. Alterar la URL es un solo cambio en un solo archivo.
5. No hay necesidad de 404 no funds. Las rutas de reserva pueden mostrar un mapa del sitio o una página de error.
6. Conveniente seguridad de acceso indirecto a los archivos de la aplicación. Declaraciones de guardia puede asegurarse de que todo el mundo está llegando a través de la canales adecuados.
7. Practicidad en el enfoque MVC.

Mi toma

La mayoría de la gente hará uso de las tres formas en sus proyectos de una manera u otra. La clave es entenderlos y elegir el que mejor se adapte a la tarea.

Si es para su uso dentro de su sitio web, es mejor usar URL relativa, así si necesita mover el sitio web a otro nombre de dominio o simplemente depurar localmente, puede hacerlo.

Echa un vistazo a lo que está haciendo stackoverflow (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 sólo es 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 por eso.

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

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

Sin embargo, una vez que empiezas a trabajar en sistemas grandes y gordos donde cambias dominios y protocolos todo el tiempo, creo que un enfoque más elegante está en orden.

Cuando comparas absoluto y relativo URLs en esencia, victorias absolutas. ¿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 URLs absolutas.

El enfoque débil para el enlace absoluto de URL es en realidad codificar la URL completa. 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 potente: detecta automáticamente tu protocolo, es fácil de configurar (literalmente establece la url una vez para toda la aplicación), etc., e inyecta tu dominio por sí solo. Lo bueno de eso: Sigues codificando usando URLs relativas, y en tiempo de ejecución la aplicación inserta tus URLs como absolutos completos sobre la marcha. Impresionante.

Viendo cómo prácticamente todos los sitios modernos utilizan algún tipo de back-end dinámico, es en el mejor interés de dicho sitio hacerlo de esa manera. URLs absolutas hacer más que solo asegurarte de dónde apuntan, también pueden mejorar el rendimiento de SEO.

Podría agregar que el argumento de que las URL absolutas de alguna manera van a cambiar 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 ese ya no es el caso. https://stackoverflow.com / es de 25 bytes, mientras que el "topbar-sprite.png " archivo que utilizan para el área de navegación del sitio pesa en 9+ kb. Eso significa que los datos de URL adicionales son .2% de los datos cargados en comparación con el archivo sprite, y ese archivo ni siquiera se considera un gran éxito de rendimiento.

Esa imagen de fondo grande, no optimizada y de página completa es mucho más probable que ralentice sus tiempos de carga.

Un post interesante sobre por qué las URLs relativas no deben ser usadas está aquí: http://yoast.com/relative-urls-issues /

Un problema que puede surgir con los familiares, por ejemplo, es que a veces el servidor las asignaciones (fíjate en proyectos grandes y desordenados) no se alinean con los nombres de archivo y el desarrollador puede hacer una suposición sobre una URL relativa que simplemente no es cierta. Acabo de ver eso hoy en un proyecto en el que estoy y trajo una página entera abajo.

O tal vez un desarrollador olvidó cambiar un puntero y, de repente, Google indexó todo su 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 ha demostrado que son más confiables. Mira el artículo anterior que da un montón de razones por las que el generador de url de Wordpress es súper impresionante.

:)

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 desea levantar su sitio y ponerlo en otro lugar donde funcionaría al instante, reduciendo posiblemente horas de depuración.

Hay un artículo bastante decente sobre URLs absolutas vs relativas, échale un vistazo.

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 la URL relativa se resuelve desde (y por lo tanto depende de) que es la URL del recurso en el que se utiliza la referencia si no se declara lo contrario.

Echa un vistazo a RFC 2396 – Appendix C para ver ejemplos de resolución de URLs relativas.

Digamos que tienes un sitio www.yourserver.com. En el directorio raíz de documentos web tienes un sub - directoy de imágenes y en el que tienes 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 está 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 relativas cuando sea posible. Si mueve el sitio a www.anotherserver.com tendría que actualizar todas las URL absolutas que apuntaban a www.yourserver.com, los relativos seguirán funcionando como está.

Para cada sistema que soporta resolución de URI relativa, tanto los URI relativos como los absolutos tienen el mismo objetivo: hacer referencia. Y se pueden usar indistintamente. Así que usted podría decidir en cada caso diferente. Técnicamente, proporcionan la misma referencia.

Para ser precisos, con cada URI relativo ya hay un URI absoluto. Y ese es el URI base que URI relativo se resuelve contra. Así que un URI relativo es en realidad una característica en la parte superior de absoluta URIs.

Y también es por eso que con URI relativos puedes hacer más como con un URI absoluto solo - esto es especialmente importante para sitios web estáticos que de otra manera no podrían ser tan flexibles de mantener en comparación con los URI absolutos.

Estos efectos positivos de la resolución relativa de URI también se pueden explotar para el desarrollo dinámico de aplicaciones web. Los URI absolutos de inflexibilidad también son más fáciles de manejar, en un entorno dinámico, por lo que para algunos desarrolladores los que no están seguros sobre la resolución de URI y cómo implementarla y administrarla correctamente (no es que siempre sea fácil) a menudo optan por usar URI absolutos 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 de URI) para evitar la inflexibilidad.

Entonces, ¿cuál es el beneficio al usar URI absolutos? Técnicamente no lo hay, pero uno diría: Los URI relativos son más complejos porque necesitan resolverse contra el llamada base-URI absoluta. Incluso la resolución se define estrictamente desde hace años, puede ejecutar sobre 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 tiene riesgo de encontrarse con un comportamiento defectuoso del cliente con una resolución relativa de URI. Entonces, ¿qué tan alto es ese riesgo en realidad? Bueno, es muy raro. Solo sé de un navegador de Internet que tenía un problema con la resolución de URI relativa. Y que no era en general, pero solo en un muy (oscuro) caso.

Junto al cliente HTTP (navegador) es quizás más complejo para un autor de documentos de hipertexto o código también. Aquí el URI absoluto tiene la ventaja de que es más fácil de probar, ya que solo puede ingresarlo tal cual en la barra de direcciones de su navegador. Sin embargo, si no es solo su trabajo de una hora, es más a menudo de mayor beneficio para usted entender realmente el manejo de URI absoluto y relativo para que pueda explotar los beneficios de la vinculación relativa.

Recomendaría encarecidamente URLs relativas para apuntar bits del mismo sitio a otros bits del mismo sitio.

No olvides que un cambio a HTTPS - incluso en el mismo sitio - va a necesitar una URL absoluta.