URLs absolutos x relativos

Gostaria de saber as diferenças entre esses dois tipos de URLs: URLs relativos (para imagens, arquivos CSS, arquivos JS, etc.) e URLs absolutos.

Além disso, qual é o melhor para usar?

Em geral, é considerado uma prática recomendada usar URLs relativos, para que seu site não seja vinculado ao URL base de onde está implantado atualmente. Por exemplo, ele poderá trabalhar no host local, bem como no seu domínio público, sem modificações.

Devo usar URLs absolutos ou relativos?

Se por URLs absolutos você quer dizer URLs incluindo o esquema (por exemplo, http / https) e o nome do host (por exemplo, seudominio.com) nunca faz isso (por recursos locais), porque será terrível manter e depurar.

Digamos que você tenha usado URL absoluta em qualquer lugar do código, como <img src="http://yourdomain.com/images/example.png">. Agora, o que acontecerá quando você estiver indo para:

• mudar para outro esquema (por exemplo, http -> https)
• alternar nomes de domínio (test.seudominio.com -> seudominio.com)

No primeiro exemplo, o que acontecerá é que você receberá avisos sobre a solicitação de conteúdo não seguro na página. Como todos os seus URLs são codificados para usar http (: //seudominio.com/images/example.png). E ao executar suas páginas em https, o navegador espera que todos os recursos sejam carregados em https para evitar vazamento de informações.

No segundo exemplo, ao colocar seu site ativo no ambiente de teste, todos os recursos ainda estão apontando para o domínio de teste, e não para o domínio ativo.

Portanto, para responder à sua pergunta sobre o uso de URLs absolutos ou relativos: sempre use URLs relativos (para recursos locais).

Quais são as diferenças entre os diferentes URLs?

Primeiro vamos dar uma olhada nos diferentes tipos de URLs que podemos usar:

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

Quais recursos esses URLs tentam acessar no servidor?

Nos exemplos abaixo, presumo que o site esteja sendo executado no seguinte local no servidor /var/www/mywebsite.

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

O URL acima (absoluto) tenta acessar o recurso /var/www/website/images/example.png. Esse tipo de URL é algo que você sempre desejaria evitar ao solicitar recursos de seu próprio site pelos motivos descritos acima. No entanto, ele tem o seu lugar. Por exemplo, se você possui um site http://yourdomain.come deseja solicitar um recurso de um domínio externo por http, deve usá-lo. Por exemplo https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

Este URL é relativo com base no esquema atual usado e quase sempre deve ser usado ao incluir recursos externos (imagens, javascripts etc.).

O que esse tipo de URL faz é usar o esquema atual da página em que está. Isso significa que você está na página http://yourdomain.come nessa página há uma tag de imagem na qual <img src="//yourdomain.com/images/example.png">o URL da imagem resolveria http://yourdomain.com/images/example.png.
Quando você estava na página http**s**://yourdomain.come nessa página há uma tag de imagem, <img src="//yourdomain.com/images/example.png">o URL da imagem resolveria https://yourdomain.com/images/example.png.

Esta impedir que os recursos de carregamento sobre https quando ela não é necessária e automaticamente garante que o recurso é solicitado através de HTTPS quando é necessário.

O URL acima é resolvido da mesma maneira no lado do servidor que o URL anterior:

O URL acima (absoluto) tenta acessar o recurso /var/www/website/images/example.png.

/images/example.png

Para recursos locais, essa é a maneira preferida de referenciá-los. Este é um URL relativo com base na raiz do documento ( /var/www/mywebsite) do seu site. Isso significa que quando você o tiver <img src="/images/example.png">, sempre resolverá /var/www/mywebsite/images/example.png.

Se em algum momento você decidir mudar de domínio, ele ainda funcionará porque é relativo.

images/example.png

Este também é um URL relativo, embora um pouco diferente do anterior. Este URL é relativo ao caminho atual. O que isso significa é que ele será resolvido para diferentes caminhos, dependendo de onde você estiver no site.

Por exemplo, quando você estiver na página http://yourdomain.come usá- <img src="images/example.png">lo, o servidor resolveria /var/www/mywebsite/images/example.pngconforme o esperado, no entanto, quando você estiver na página http://yourdomain.com/some/pathe usar exatamente a mesma tag de imagem para a qual resolverá repentinamente /var/www/mywebsite/some/path/images/example.png.

Quando usar o que?

Ao solicitar recursos externos, você provavelmente deseja usar um URL relativo ao esquema (a menos que queira forçar um esquema diferente) e ao lidar com recursos locais, deseja usar URLs relativos com base na raiz do documento.

Um documento de exemplo:

<!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>

Algumas (meio) duplicatas

• Maneira segura de escrever URLs que se transferem entre ambientes
• Qual é a maneira correta de vincular uma imagem no site?

Veja isto: 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

Um URL absoluto inclui as partes antes da parte "path" - em outras palavras, inclui o esquema (o httpin http://foo/bar/baz) e o nome do host (o fooin http://foo/bar/baz) (e, opcionalmente, port, userinfo e port).

Os URLs relativos começam com um caminho.

URLs absolutos são, bem, absolutos: a localização do recurso pode ser resolvida observando apenas o próprio URL. Um URL relativo é, de certo modo, incompleto: para resolvê-lo, você precisa do esquema e do nome do host, e eles geralmente são retirados do contexto atual. Por exemplo, em uma página da web em

http://myhost/mypath/myresource1.html

você poderia colocar um link assim

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

No hrefatributo do link, um URL relativo é usado e, se ele for clicado, ele deverá ser resolvido para segui-lo. Nesse caso, o contexto atual é

http://myhost/mypath/myresource1.html

portanto, o esquema, o nome do host e o caminho principal são pegos e anexados pages/page1, produzindo

http://myhost/mypath/pages/page1

Se o link tivesse sido:

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

(observe a /exibição no início do URL), ele teria sido resolvido como

http://myhost/pages/page1

porque o líder /indica a raiz do host.

Em um aplicativo da Web, aconselho o uso de URLs relativos para todos os recursos que pertencem ao seu aplicativo. Dessa forma, se você alterar o local das páginas, tudo continuará funcionando. Quaisquer recursos externos (podem ser páginas completamente fora do aplicativo, mas também conteúdo estático que você entrega por meio de uma rede de entrega de conteúdo) devem sempre ser apontados para o uso de URLs absolutos: se você não o fizer, simplesmente não há como localizá-los, porque eles residir em um servidor diferente.

Suponha que estamos criando um subsite cujos arquivos estão na pasta http://site.ru/shop .

1. URL absoluto

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 relativo

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

Link from product page to home page
href="../../"

Embora o URL relativo pareça mais curto que o absoluto, mas os URLs absolutos são mais preferíveis, pois um link pode ser usado inalterado em qualquer página do site.

Casos intermediários

Consideramos dois casos extremos: URLs "absolutamente" absolutos e "absolutamente" relativos. Mas tudo é relativo neste mundo. Isso também se aplica a URLs. Toda vez que você diz sobre URL absoluto, sempre deve especificar em relação a quê.

3. URL relativo ao protocolo

Link to home page
href="//sites.ru/shop/"

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

O Google recomenda esse URL. Agora, no entanto, é geralmente considerado que http: // e https: // são sites diferentes.

4. URL relativo à raiz

Ou seja, em relação à pasta raiz do domínio.

Link to home page
href="/shop/"

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

É uma boa opção se todas as páginas estiverem no mesmo domínio. Quando você move o site para outro domínio, não precisa fazer uma substituição em massa do nome de domínio nos URLs.

5. URL relativo à base (relativo à página inicial)

A tag <base> especifica o URL base, que é adicionado automaticamente a todos os links e âncoras relativos. A tag base não afeta os links absolutos. Como URL base, especificaremos a página inicial: <base href = "http://sites.ru/shop/">.

Link to home page
href=""

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

Agora você pode mover seu site não apenas para qualquer domínio, mas em qualquer subpasta. Lembre-se de que, embora os URLs pareçam relativos, na verdade eles são absolutos. Preste atenção especialmente às âncoras. Para navegar pela página atual, precisamos escrever href = "camisetas / camiseta-vida-da-vida-é-boa / # comentários" not href = "# comentários". Este último será lançado na página inicial.

Conclusão

Para links internos, uso URLs relativas à base (5). Para links externos e boletins, eu uso URLs absolutas (1).

Na verdade, existem três tipos que devem ser discutidos explicitamente. Na prática, embora os URLs tenham sido abstraídos para serem manipulados em um nível mais baixo, eu diria que os desenvolvedores poderiam passar a vida inteira sem escrever um único URL manualmente.

Absoluto

URLs absolutos vinculam seu código ao protocolo e domínio. Isso pode ser superado com URLs dinâmicos.

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

Prós absolutos:

1. Controle - O subdomínio e o protocolo podem ser controlados. As pessoas que entrarem em um subdomínio obscuro serão canalizadas para o subdomínio apropriado. Você pode alternar entre seguro e não seguro, conforme apropriado.

2. Configurável - os desenvolvedores adoram que as coisas sejam absolutas. Você pode criar algoritmos puros ao usar URLs absolutos. Os URLs podem ser configurados para que um URL possa ser atualizado em todo o site com uma única alteração em um único arquivo de configuração.

3. Clarividência - Você pode procurar as pessoas que estão raspando o seu site ou talvez pegar alguns links externos extras.

Root Relative

Os URLs relativos à raiz vinculam seu código ao URL base. Isso pode ser superado com URLs dinâmicos e / ou tags de base .

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

Profissionais relativos à raiz:

1. Configurável - a tag base os torna relativos a qualquer raiz que você escolher, facilitando a troca de domínios e a implementação de modelos.

Relativo

URLs relativos vinculam seu código à estrutura de diretórios. Não há como superar isso. URLs relativos são úteis apenas em sistemas de arquivos para percorrer diretórios ou como um atalho para uma tarefa servil.

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

Contras relativas:

1. CONFUSO - Quantos pontos são esses? quantas pastas é essa? Onde está o arquivo? Por que não está funcionando?

2. MANUTENÇÃO - Se um arquivo for movido acidentalmente, os recursos deixarão de ser carregados, os links enviarão o usuário para as páginas erradas; os dados do formulário poderão ser enviados para a página incorreta. Se um arquivo PRECISA ser movido, todos os recursos que serão encerrados e todos os links incorretos precisam ser atualizados.

3. NÃO ESCALA - Quando as páginas da Web se tornam mais complexas e as visualizações começam a ser reutilizadas em várias páginas, os links relativos são relativos ao arquivo em que foram incluídos. Se você tiver um snippet de navegação em HTML que estará em todas as páginas, o parente será relativo a vários lugares diferentes. A primeira coisa que as pessoas percebem quando começam a criar um modelo é que precisam de uma maneira de gerenciar os URLs.

4. COMPUTED - Eles são implementados pelo seu navegador (espero que de acordo com a RFC). Veja o capítulo 5 na RFC3986 .

5. OOPS! - Erros ou erros de digitação podem resultar em armadilhas.

A evolução das rotas

Os desenvolvedores pararam de escrever URLs no sentido discutido aqui. Todas as solicitações são para o arquivo de índice de um site e contêm uma string de consulta, também conhecida como rota. A rota pode ser considerada como uma mini URL que informa ao seu aplicativo o conteúdo a ser gerado.

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

Rotas Profissionais:

1. Todas as vantagens dos URLs absolutos.
2. Uso de qualquer caractere no URL.
3. Mais controle (bom para SEO).
4. Capacidade de gerar URLs algoritmicamente. Isso permite que os URLs sejam configuráveis. Alterar o URL é uma única alteração em um único arquivo.
5. Não há necessidade de 404 não encontrado. As rotas de fallback podem exibir um mapa do site ou uma página de erro.
6. Segurança conveniente do acesso indireto aos arquivos do aplicativo. As declarações de guarda podem garantir que todos cheguem pelos canais adequados.
7. Praticidade na abordagem MVC.

Minha vez

A maioria das pessoas fará uso de todas as três formas em seus projetos de uma maneira ou de outra. A chave é entendê-los e escolher o que melhor se adequa à tarefa.

Se for para uso em seu site, é uma prática recomendada usar URL relativo, como este, se você precisar mover o site para outro nome de domínio ou apenas depurar localmente, poderá.

Dê uma olhada no que o stackoverflow está fazendo (ctrl + U no firefox):

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

Em alguns casos, eles usam URLs absolutos:

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

... mas essa é apenas uma prática recomendada para melhorar a velocidade. No seu caso, não parece que você esteja fazendo algo assim, então eu não me preocuparia.

Vou ter que discordar da maioria aqui.

Eu acho que o esquema relativo de URL é "bom" quando você deseja colocar algo em funcionamento rapidamente e não pensar fora da caixa, principalmente se o seu projeto for pequeno com poucos desenvolvedores (ou apenas você).

No entanto, quando você começa a trabalhar em sistemas grandes e gordurosos nos quais alterna domínios e protocolos o tempo todo, acredito que uma abordagem mais elegante esteja em ordem.

Quando você compara URLs absolutos e relativos em essência, o Absolute vence. Por quê? Porque nunca vai quebrar. Sempre. Uma URL absoluta é exatamente o que diz. O problema é quando você precisa manter seus URLs absolutos.

A abordagem fraca para a vinculação absoluta de URL é realmente codificar todo o URL. Não é uma ótima idéia, e provavelmente o culpado por que as pessoas as vêem como perigosas / más / irritantes de manter. Uma abordagem melhor é escrever um gerador de URL fácil de usar. Elas são fáceis de escrever e podem ser incrivelmente poderosas - detectando automaticamente seu protocolo, fácil de configurar (literalmente defina o URL uma vez para todo o aplicativo), etc, e injeta seu domínio por si só. O legal disso: você continua codificando usando URLs relativos e, em tempo de execução, o aplicativo insere seus URLs como absolutos completos em tempo real. Impressionante.

Considerando que praticamente todos os sites modernos usam algum tipo de back-end dinâmico, é do interesse do site fazê-lo dessa maneira. URLs absolutos fazem mais do que apenas garantir que eles apontam para eles - eles também podem melhorar o desempenho do SEO.

Devo acrescentar que o argumento de que URLs absolutos irão de alguma forma alterar o tempo de carregamento da página é um mito. Se o seu domínio pesar mais do que alguns bytes e você estiver em um modem dial-up nos anos 80, com certeza. Mas esse não é mais o caso. https://stackoverflow.com/ tem 25 bytes, enquanto o arquivo "topbar-sprite.png" que eles usam para a área de navegação do site pesa mais de 9 kb. Isso significa que os dados adicionais da URL representam 0,2% dos dados carregados em comparação com o arquivo sprite, e esse arquivo nem sequer é considerado um grande problema de desempenho.

Essa imagem de fundo grande, não otimizada e de página inteira tem muito mais chances de diminuir o tempo de carregamento.

Um post interessante sobre por que URLs relativos não devem ser usados ​​está aqui: http://yoast.com/relative-urls-issues/

Um problema que pode surgir com os parentes, por exemplo, é que, às vezes, os mapeamentos de servidores (lembre-se de grandes projetos desarrumados) não se alinham aos nomes dos arquivos e o desenvolvedor pode assumir uma URL relativa que simplesmente não é verdade. Eu vi isso hoje em um projeto em que estou e trouxe uma página inteira para baixo.

Ou talvez um desenvolvedor tenha esquecido de mudar um ponteiro e, de repente, o Google indexou todo o seu ambiente de teste. Ops - conteúdo duplicado (ruim para SEO!).

Os absolutos podem ser perigosos, mas quando usados ​​corretamente e de uma maneira que não podem prejudicar sua construção eles são comprovadamente mais confiáveis. Veja o artigo acima, que fornece várias razões pelas quais o gerador de URL do Wordpress é super incrível.

:)

Na maioria dos casos, os URLs relativos são o caminho a percorrer, eles são portáteis por natureza, o que significa que se você deseja elevar seu site e colocá-lo em alguém onde mais ele funcionaria instantaneamente, reduzindo possivelmente horas de depuração.

Há um artigo bastante decente sobre URLs absolutos e relativos , confira.

Um URL que comece com a parte esquema de URL e específico esquema ( http://, https://, ftp://, etc.) é um URL absoluto.

Qualquer outra URL é uma URL relativa e precisa de uma URL base da qual a URL relativa é resolvida (e, portanto, depende), que é a URL do recurso em que a referência é usada, se não declarada de outra forma.

Dê uma olhada no RFC 2396 - Apêndice C para obter exemplos de resolução de URLs relativos.

Digamos que você tenha um site www.yourserver.com. No diretório raiz dos documentos da web, você tem um subdiretório de imagens e em myimage.jpg.

Uma URL absoluta define a localização exata do documento, por exemplo:

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

Uma URL relativa define a localização relativa ao diretório atual , por exemplo, desde que você esteja no diretório raiz da web em que sua imagem está:

images/myimage.jpg

(relativo a esse diretório raiz)

Você sempre deve usar URLS relativos sempre que possível. Se você mover o site para www.anotherserver.com, precisará atualizar todos os URLs absolutos que apontam para www.yourserver.com, os relativos continuarão funcionando como estão.

Para todo sistema que suporta resolução relativa de URI, URIs relativos e absolutos cumprem o mesmo objetivo: referência. E eles podem ser usados ​​de forma intercambiável. Então você pode decidir em cada caso de maneira diferente. Tecnicamente, eles fornecem a mesma referência.

Para ser preciso, com cada URI relativo já existe um URI absoluto. E esse é o URI base em que o URI relativo é resolvido. Portanto, um URI relativo é realmente um recurso sobre os URIs absolutos.

E é também por isso que, com URIs relativos, você pode fazer mais do que com um URI absoluto - isso é especialmente importante para sites estáticos que, de outra forma, não poderiam ser tão flexíveis de manter em comparação com URIs absolutos.

Esses efeitos positivos da resolução relativa de URI também podem ser explorados para o desenvolvimento dinâmico de aplicativos da web. As inflexibilidade que os URIs absolutos introduzem também são mais fáceis de lidar, em um ambiente dinâmico, portanto, para alguns desenvolvedores que não têm certeza sobre a resolução de URI e como implementá-lo e gerenciá-lo adequadamente (não que seja sempre fácil), muitas vezes optam pelo uso absoluto URIs em uma parte dinâmica de um site, pois podem introduzir outros recursos dinâmicos (por exemplo, variável de configuração que contém o prefixo de URI) para solucionar a inflexibilidade.

Então, qual é o benefício do uso de URIs absolutos? Tecnicamente, não existe, mas eu diria: URIs relativos são mais complexos porque precisam ser resolvidos com base no chamado URI base absoluto. Mesmo que a resolução seja rigorosamente definida, há anos, você pode atropelar um cliente com erro na resolução de URI. Como os URIs absolutos não precisam de nenhuma resolução, o uso de URIs absolutos não corre o risco de ocorrer um comportamento defeituoso do cliente com uma resolução relativa de URIs. Então, qual é realmente esse risco? Bem, é muito raro. Eu sei apenas sobre um navegador da Internet que teve um problema com a resolução relativa de URI. E isso não foi geralmente, mas apenas em um caso muito (obscuro).

Ao lado do cliente HTTP (navegador), talvez seja mais complexo para um autor de documentos ou códigos de hipertexto. Aqui, o URI absoluto tem o benefício de ser mais fácil de testar, pois você pode inseri-lo como está na barra de endereço do navegador. No entanto, se não for apenas um trabalho de uma hora, é mais benéfico para você entender o manuseio absoluto e relativo de URI, para que você possa realmente explorar os benefícios do vínculo relativo.

Eu recomendaria sinceramente URLs relativas para apontar bits do mesmo site para outros bits do mesmo site.

Não esqueça que uma alteração no HTTPS - mesmo que no mesmo site - precise de um URL absoluto.