Respuestas:
En general, se considera una práctica recomendada el uso de URL relativas, de modo que su sitio web no estará vinculado a la URL base de donde se implementa actualmente. Por ejemplo, podrá trabajar en localhost, así como en su dominio público, sin modificaciones.
Si por URL absolutas te refieres a URL que incluyen el esquema (por ejemplo, http / https) y el nombre de host (por ejemplo, tudominio.com), nunca lo hagas (por recursos locales) porque será terrible de mantener y depurar.
Digamos que ha utilizado URL absoluta en todas partes en su código como <img src="http://yourdomain.com/images/example.png">. Ahora qué sucederá cuando vayas a:
En el primer ejemplo, lo que sucederá es que recibirá advertencias sobre el contenido no seguro que se solicita en la página. Debido a que todas sus URL están codificadas para usar http (: //yourdomain.com/images/example.png). Y cuando ejecuta sus páginas a través de https, 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 que todos los recursos siguen apuntando a su dominio de prueba en lugar de a su dominio en vivo.
Entonces, para responder a su pregunta sobre si usar URL absolutas o relativas: siempre use URL relativas (para recursos locales).
Primero echemos un vistazo a los diferentes tipos de URL que podemos usar:
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.pngEn 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 (absoluta) anterior intenta acceder al recurso /var/www/website/images/example.png. Este tipo de URL es algo que siempre querrá evitar al solicitar recursos de su propio sitio web por los motivos descritos anteriormente. Sin embargo, tiene su lugar. Por ejemplo, si tiene un sitio web http://yourdomain.comy desea solicitar un recurso de un dominio externo a través de http, debe usarlo. Por ej https://externalsite.com/path/to/image.png.
//yourdomain.com/images/example.png
Esta URL es relativa según el esquema actual utilizado y casi siempre debe usarse 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 está en la página http://yourdomain.comy en esa página hay una etiqueta <img src="//yourdomain.com/images/example.png">de imagen en la que se resolvería la URL de la imagen http://yourdomain.com/images/example.png.
Cuando hubiera estado en la página http**s**://yourdomain.comy en esa página hay una etiqueta <img src="//yourdomain.com/images/example.png">de imagen en la que se resolvería la URL de la imagen https://yourdomain.com/images/example.png.
Este impiden que los recursos de carga a través de HTTPS cuando no es necesaria y automáticamente se asegura que se solicita el recurso a través de HTTPS cuando se necesitaba.
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 hacer referencia a ellos. Esta es una URL relativa basada en la raíz del documento ( /var/www/mywebsite) de su sitio web. Esto significa que cuando lo tengas <img src="/images/example.png">, siempre se resolverá /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 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 está en la página http://yourdomain.comy lo usa <img src="images/example.png">, se resolvería en el servidor /var/www/mywebsite/images/example.pngcomo se esperaba, sin embargo, cuando esté en la página http://yourdomain.com/some/pathy use exactamente la misma etiqueta de imagen, de repente se resolverá /var/www/mywebsite/some/path/images/example.png.
Cuando solicite recursos externos, lo más probable es que desee usar una URL relativa al esquema (a menos que desee forzar un esquema diferente) y cuando trate con recursos locales, desee 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>Vea esto: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password@example.com: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 extensionUna URL absoluta incluye las partes antes de la parte "camino" - en otras palabras, se incluye el esquema (la httpen http://foo/bar/baz) y el nombre de host (el fooen http://foo/bar/baz) (y opcionalmente el puerto, userinfo y puerto).
Las URL relativas comienzan con una ruta.
Las URL absolutas son, bueno, absolutas: la ubicación del recurso se puede resolver mirando solo la url misma. Una URL relativa es, en cierto sentido, incompleta: para resolverla, 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.htmlpodrías poner un enlace así
<a href="pages/page1">click me</a>En el hrefatributo del enlace, se utiliza una URL relativa, y si se hace clic en ella, debe resolverse para poder seguirla. En este caso, el contexto actual es
http://myhost/mypath/myresource1.htmlentonces el esquema, el nombre de host y la ruta principal de estos se toman y anteponen pages/page1, produciendo
http://myhost/mypath/pages/page1Si el enlace hubiera sido:
<a href="/pages/page1">click me</a>(tenga en cuenta que /aparece al comienzo de la URL), entonces se habría resuelto como
http://myhost/pages/page1porque el inicio /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 contenido estático que entregue a través de una red de entrega de contenido) siempre debe apuntar al uso de URL absolutas: si no lo hace, simplemente no hay forma de ubicarlas, porque residir en un servidor diferente.
//example.com/…, ?foobary #foobartambién son URL relativas y no comienzan con la ruta de la URL (bueno, pues ?foobarpuede decir que comienza con una ruta vacía ).
//example.com/…URL de tipo se llaman relativas? Eso es nuevo para mí.
Supongamos que estamos creando un subsitio cuyos archivos están en la carpeta http://site.ru/shop .
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/"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.
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 con qué.
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.
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 reemplazos masivos del nombre de dominio en las URL.
La etiqueta <base> 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: <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 cualquier dominio, sino a cualquier subcarpeta. Solo tenga en cuenta que, aunque las URL parecen ser relativas, de hecho son absolutas. Presta especial atención a las anclas. Para navegar dentro de la página actual tenemos que escribir href = "t-shirts / t-shirt-life-is-good / # comments" not href = "# comments". Este último se lanzará en la página de inicio.
Para los enlaces internos, uso las URL relativas a la base (5). Para enlaces externos y boletines, uso URL absolutas (1).
Realmente hay tres tipos que deberían discutirse explícitamente. En la práctica, aunque las URL se han extraído para que se manejen en un nivel inferior, iría tan lejos como para decir que los desarrolladores podrían pasar toda su vida sin escribir una sola URL a mano.
Las URL absolutas vinculan su código al protocolo y al 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 absolutos:
Control : el subdominio y el protocolo se pueden controlar. Las personas que ingresen a través de un subdominio oscuro se canalizarán al subdominio apropiado. Puede ir y venir entre seguro y no seguro, según corresponda.
Configurable : a los desarrolladores les encanta que las cosas sean absolutas. Puede diseñar algoritmos limpios 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 un solo archivo de configuración.
Clarividencia : puede buscar a las personas que raspan su sitio o tal vez recoger algunos enlaces externos adicionales.
Las URL relativas a la 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>Pros relativos de la raíz:
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 atravesar directorios o como acceso directo para una tarea de baja categoría.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />Contras Relativas:
CONFUSIÓN - ¿Cuántos puntos es eso? ¿Cuántas 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 comienzan a reutilizarse en varias páginas, los enlaces relativos serán relativos al archivo en el que se incluyeron. Si tiene un fragmento de HTML de navegación que estará en cada página, el pariente 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 de acuerdo con RFC). Consulte el capítulo 5 en RFC3986 .
¡Vaya! - Errores o errores tipográficos pueden resultar en trampas de araña.
Los desarrolladores han dejado de escribir URL 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 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>Rutas Pros:
La mayoría de las personas utilizarán las tres formas en sus proyectos de una forma u otra. La clave es comprenderlos y elegir el que mejor se adapte a la tarea.
Si es para usar dentro de su sitio web, es una mejor 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 stackoverflow (ctrl + U en firefox):
<a href="/users/recent/90691"> // Link to an internal elementEn algunos casos usan URL 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 su caso, no parece que esté haciendo algo así, así que no me preocuparía.
Voy a tener que estar en desacuerdo con la mayoría aquí.
Creo que el esquema de URL relativo está "bien" cuando quieres poner en marcha algo rápidamente 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 comience a trabajar en sistemas grandes y grasos donde cambie de dominio y de protocolo todo el tiempo, creo que es necesario un enfoque más elegante.
Cuando compara 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 el enlace absoluto de la 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 un generador de URL fácil de usar. Estos son fáciles de escribir y pueden ser increíblemente potentes: detectar automáticamente su protocolo, fácil de configurar (configurar literalmente la url una vez para toda la aplicación), etc., e inyecta su dominio por sí mismo. Lo bueno de eso: continúa codificando utilizando URL relativas, y en tiempo de ejecución la aplicación inserta sus URL como absolutas completas sobre la marcha. Increíble.
Dado que prácticamente todos los sitios modernos utilizan algún tipo de back-end dinámico, lo mejor para él es hacerlo de esa manera. Las URL absolutas hacen más que solo asegurarse de a 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 va 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/ tiene 25 bytes, mientras que el archivo "topbar-sprite.png" que usan para el área de navegación del sitio pesa más de 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 impacto en el rendimiento.
Esa imagen de fondo grande, no optimizada, de página completa es mucho más probable que 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 proyectos grandes y desordenados) no se alinean con los nombres de los archivos y el desarrollador puede suponer una URL relativa que simplemente no es cierto. Acabo de ver eso hoy en un proyecto en el que estoy y me 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 adecuadamente y de una manera que no puede romper su construcción , se demuestra que son más confiables. Mire el artículo anterior que da muchas razones por las cuales el generador de URL de Wordpress es súper increíble.
:)
/para vincular a la ruta base? es decir, /products/wallets/thing.htmlcomo opuesto a thing.htmlopuesto ahttp://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')para construir una URL absoluta usando la URL del sitio y la información de ruta con la opción de hacerlo a través de HTTPS.
En la mayoría de los casos, las URL relativas son el camino a seguir, son portables por naturaleza, lo que significa que si desea levantar su sitio y colocarlo en otro lugar donde funcione instantáneamente, reduciendo posiblemente las horas de depuración.
Hay un artículo bastante decente sobre las URL absolutas frente a las relativas , échale un vistazo.
Un URL que comienza con la parte esquema de URL y específica esquema ( http://, https://, ftp://, etc.) es una URL absoluta.
Cualquier otra URL es una URL relativa y necesita una URL base a partir de la cual se resuelve la URL relativa (y, por lo tanto, depende) de esa es 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 resolución de URL relativas.
Digamos que tiene un sitio www.yourserver.com. En el directorio raíz de documentos web tiene una subdirección de imágenes y en myimage.jpg.
Una URL absoluta define la ubicación exacta del documento, por ejemplo:
http://www.yourserver.com/images/myimage.jpgUna 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 URLS relativos 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, las relativas seguirán funcionando tal como están.
Para cada sistema que admita una resolución de URI relativa, tanto los URI relativos como los absolutos sirven para el mismo objetivo: hacer referencia. Y se pueden usar indistintamente. Para que pueda 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 base contra el que se resuelve el URI relativo. Entonces, un URI relativo es en realidad una característica además de los URI absolutos.
Y también es por eso que con los URI relativos puede hacer más como 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 de URI también pueden aprovecharse para el desarrollo dinámico de aplicaciones web. Los URI absolutos de inflexibilidad que introducen 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 implementarla y administrarla adecuadamente (no siempre es fácil) a menudo optan por usar absoluto 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 existe, pero diría que uno: los URI relativos son más complejos porque deben resolverse contra el llamado URI de base absoluta. Incluso la resolución está estrictamente definida desde hace años, puede atropellar 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 tiene riesgo de encontrarse con un comportamiento defectuoso del cliente con una resolución de URI relativa. Entonces, ¿qué tan alto es ese riesgo en realidad? Bueno, es muy raro. Solo conozco un navegador de Internet que tuvo un problema con la resolución relativa de URI. Y eso no fue generalmente sino solo en un caso muy (oscuro).
Al lado del cliente HTTP (navegador) es quizás más complejo también para un autor de documentos o códigos de hipertexto. Aquí, el URI absoluto tiene el beneficio de que es más fácil de probar, ya que 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 beneficioso para usted comprender realmente el manejo absoluto y relativo de URI para que pueda aprovechar los beneficios de la vinculación relativa.