URL absolues et URL relatives

Je voudrais connaître les différences entre ces deux types d'URL: les URL relatives (pour les images, les fichiers CSS, les fichiers JS, etc.) et les URL absolues.

De plus, lequel est préférable d'utiliser?

En général, il est considéré comme la meilleure pratique d'utiliser des URL relatives, afin que votre site Web ne soit pas lié à l'URL de base de l'endroit où il est actuellement déployé. Par exemple, il pourra fonctionner sur localhost, ainsi que sur votre domaine public, sans modifications.

Dois-je utiliser des URL absolues ou relatives?

Si par URL absolues, vous entendez des URL incluant le schéma (par exemple http / https) et le nom d'hôte (par exemple votredomaine.com) ne le faites jamais (pour les ressources locales) car ce sera terrible à maintenir et à déboguer.

Supposons que vous ayez utilisé une URL absolue partout dans votre code, comme <img src="http://yourdomain.com/images/example.png">. Maintenant, que se passera-t-il lorsque vous allez:

• passer à un autre schéma (par exemple http -> https)
• changer de nom de domaine (test.votredomaine.com -> votredomaine.com)

Dans le premier exemple, ce qui se passera, c'est que vous obtiendrez des avertissements concernant le contenu dangereux demandé sur la page. Parce que toutes vos URL sont codées en dur pour utiliser http (: //votredomaine.com/images/example.png). Et lors de l'exécution de vos pages sur https, le navigateur s'attend à ce que toutes les ressources soient chargées sur https pour éviter la fuite d'informations.

Dans le deuxième exemple, lorsque vous mettez votre site en ligne à partir de l'environnement de test, cela signifie que toutes les ressources pointent toujours vers votre domaine de test au lieu de votre domaine en ligne.

Donc, pour répondre à votre question sur l'utilisation des URL absolues ou relatives: utilisez toujours des URL relatives (pour les ressources locales).

Quelles sont les différences entre les différentes URL?

Voyons d'abord les différents types d'URL que nous pouvons utiliser:

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

À quelles ressources ces URL essaient-elles d'accéder sur le serveur?

Dans les exemples ci-dessous, je suppose que le site Web s'exécute à partir de l'emplacement suivant sur le serveur /var/www/mywebsite.

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

L'URL ci-dessus (absolue) tente d'accéder à la ressource /var/www/website/images/example.png. Ce type d'URL est quelque chose que vous voudriez toujours éviter pour demander des ressources à partir de votre propre site Web pour la raison décrite ci-dessus. Mais il a sa place. Par exemple, si vous avez un site Web http://yourdomain.comet que vous souhaitez demander une ressource à un domaine externe via https, vous devez l'utiliser. Par exemple https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

Cette URL est relative en fonction du schéma actuel utilisé et devrait presque toujours être utilisée lors de l'inclusion de ressources externes (images, javascripts, etc.).

Ce que ce type d'URL fait, c'est utiliser le schéma actuel de la page sur laquelle il se trouve. Cela signifie que vous êtes sur la page http://yourdomain.comet sur cette page est une balise d'image dans laquelle <img src="//yourdomain.com/images/example.png">l'URL de l'image se résoudrait http://yourdomain.com/images/example.png.
Lorsque vous auriez été sur la page http**s**://yourdomain.comet que cette page est une balise d'image, <img src="//yourdomain.com/images/example.png">l'URL de l'image se résoudrait https://yourdomain.com/images/example.png.

Cela empêche le chargement des ressources sur https lorsqu'elle n'est pas nécessaire et garantit automatiquement que la ressource est demandée sur https lorsqu'elle est nécessaire.

L'URL ci-dessus se résout de la même manière côté serveur que l'URL précédente:

L'URL ci-dessus (absolue) tente d'accéder à la ressource /var/www/website/images/example.png.

/images/example.png

Pour les ressources locales, c'est la manière préférée de les référencer. Il s'agit d'une URL relative basée sur la racine du document ( /var/www/mywebsite) de votre site Web. Cela signifie que lorsque vous l'avez, <img src="/images/example.png">il sera toujours résolu /var/www/mywebsite/images/example.png.

Si à un moment donné vous décidez de changer de domaine, cela fonctionnera toujours car il est relatif.

images/example.png

Il s'agit également d'une URL relative bien qu'un peu différente de la précédente. Cette URL est relative au chemin actuel. Cela signifie qu'il se résoudra en différents chemins en fonction de l'endroit où vous vous trouvez sur le site.

Par exemple, lorsque vous êtes sur la page http://yourdomain.comet que vous l'utilisez, <img src="images/example.png">cela se résoudrait sur le serveur /var/www/mywebsite/images/example.pngcomme prévu, mais lorsque vous êtes sur la page http://yourdomain.com/some/pathet que vous utilisez exactement la même balise d'image, elle se résoudra soudainement /var/www/mywebsite/some/path/images/example.png.

Quand utiliser quoi?

Lorsque vous demandez des ressources externes, vous souhaiterez probablement utiliser une URL relative au schéma (sauf si vous souhaitez forcer un schéma différent) et lorsque vous traitez avec des ressources locales, vous souhaitez utiliser des URL relatives basées sur la racine du document.

Un exemple de document:

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

Quelques (un peu) doublons

• Manière sûre d'écrire des URL qui transfèrent à travers des environnements
• quelle est la bonne façon de lier l'image dans le site Web?

Voir ceci: 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

Une URL absolue inclut les parties avant la partie "chemin" - en d'autres termes, elle inclut le schéma (le httpin http://foo/bar/baz) et le nom d'hôte (le fooin http://foo/bar/baz) (et éventuellement port, userinfo et port).

Les URL relatives commencent par un chemin.

Les URL absolues sont, enfin, absolues: l'emplacement de la ressource peut être résolu en ne regardant que l'URL elle-même. Une URL relative est en un sens incomplète: pour la résoudre, vous avez besoin du schéma et du nom d'hôte, et ceux-ci sont généralement tirés du contexte actuel. Par exemple, dans une page Web à

http://myhost/mypath/myresource1.html

vous pourriez mettre un lien comme ça

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

Dans l' hrefattribut du lien, une URL relative est utilisée, et si elle est cliquée, elle doit être résolue afin de la suivre. Dans ce cas, le contexte actuel est

http://myhost/mypath/myresource1.html

de sorte que le schéma, le nom d'hôte et le chemin d'accès principal de ceux-ci sont pris et ajoutés pages/page1, ce qui donne

http://myhost/mypath/pages/page1

Si le lien aurait été:

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

(notez l’ /apparition au début de l’url) alors il aurait été résolu comme

http://myhost/pages/page1

car le début /indique la racine de l'hôte.

Dans une application Web, je vous conseille d'utiliser des URL relatives pour toutes les ressources qui appartiennent à votre application. De cette façon, si vous changez l'emplacement des pages, tout continuera à fonctionner. Toutes les ressources externes (peuvent être des pages complètement en dehors de votre application, mais aussi du contenu statique que vous diffusez via un réseau de diffusion de contenu) doivent toujours être pointées vers l'utilisation d'URL absolues: si vous ne le faites pas, il n'y a tout simplement aucun moyen de les localiser, car elles résider sur un autre serveur.

Supposons que nous créons un sous-site dont les fichiers se trouvent dans le dossier http://site.ru/shop .

1. URL absolue

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 relative

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

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

Bien que l'URL relative soit plus courte que l'URL absolue, les URL absolues sont plus préférables, car un lien peut être utilisé tel quel sur n'importe quelle page du site.

Cas intermédiaires

Nous avons considéré deux cas extrêmes: les URL "absolument" absolues et "absolument" relatives. Mais tout est relatif dans ce monde. Cela s'applique également aux URL. Chaque fois que vous parlez d'URL absolue, vous devez toujours spécifier par rapport à quoi.

3. URL relative au protocole

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

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

Google recommande une telle URL. Maintenant, cependant, il est généralement considéré que http: // et https: // sont des sites différents.

4. URL relative à la racine

C'est à dire par rapport au dossier racine du domaine.

Link to home page
href="/shop/"

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

C'est un bon choix si toutes les pages sont dans le même domaine. Lorsque vous déplacez votre site vers un autre domaine, vous n'avez pas à effectuer un remplacement massif du nom de domaine dans les URL.

5. URL relative à la base (relative à la page d'accueil)

La balise <base> spécifie l'URL de base, qui est automatiquement ajoutée à tous les liens et ancres relatifs. La balise de base n'affecte pas les liens absolus. En tant qu'URL de base, nous spécifierons la page d'accueil: <base href = "http://sites.ru/shop/">.

Link to home page
href=""

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

Vous pouvez maintenant déplacer votre site non seulement vers n'importe quel domaine, mais dans n'importe quel sous-dossier. Gardez juste à l'esprit que, même si les URL semblent relatives, en fait, elles sont absolues. Faites particulièrement attention aux ancres. Pour naviguer dans la page actuelle, nous devons écrire href = "t-shirts / t-shirt-life-is-good / # comments" not href = "# comments". Ce dernier jettera sur la page d'accueil.

Conclusion

Pour les liens internes, j'utilise des URL relatives à la base (5). Pour les liens externes et les newsletters, j'utilise des URL absolues (1).

Il y a vraiment trois types qui devraient être discutés explicitement. En pratique, bien que les URL aient été résumées pour être traitées à un niveau inférieur et j'irais jusqu'à dire que les développeurs peuvent parcourir toute leur vie sans écrire une seule URL à la main.

Absolu

Des URL absolues lient votre code au protocole et au domaine. Cela peut être surmonté avec des URL dynamiques.

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

Avantages absolus:

1. Contrôle - Le sous-domaine et le protocole peuvent être contrôlés. Les personnes qui entrent par un sous-domaine obscur seront dirigées vers le sous-domaine approprié. Vous pouvez aller et venir entre sécurisé et non sécurisé selon le cas.

2. Configurable - Les développeurs aiment que les choses soient absolues. Vous pouvez concevoir des algorithmes soignés lorsque vous utilisez des URL absolues. Les URL peuvent être configurées de sorte qu'une URL puisse être mise à jour à l'échelle du site avec une seule modification dans un seul fichier de configuration.

3. Voyance - Vous pouvez rechercher les personnes qui grattent votre site ou peut-être récupérer des liens externes supplémentaires.

Racine relative

Les URL relatives racine relient votre code à l'URL de base. Cela peut être surmonté avec des URL dynamiques et / ou des balises de base .

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

Root Relative Pros:

1. Configurable - La balise de base les rend relatifs à n'importe quelle racine que vous choisissez, ce qui facilite le changement de domaine et l'implémentation de modèles.

Relatif

Les URL relatives lient votre code à la structure du répertoire. Il n'y a aucun moyen de surmonter cela. Les URL relatives ne sont utiles que dans les systèmes de fichiers pour parcourir les répertoires ou comme raccourci pour une tâche subalterne.

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

Inconvénients relatifs:

1. CONFONDRE - Combien de points est-ce? combien de dossiers est-ce? Où est le dossier? Pourquoi ça ne marche pas?

2. MAINTENANCE - Si un fichier est déplacé accidentellement, les ressources quittent le chargement, les liens envoient l'utilisateur vers les mauvaises pages, les données du formulaire peuvent être envoyées vers la page incorrecte. Si un fichier a besoin d'être déplacé, toutes les ressources qui vont quitter le chargement et tous les liens qui vont être incorrects doivent être mis à jour.

3. N'ÉCHELLE PAS - Lorsque les pages Web deviennent plus complexes et que les vues commencent à être réutilisées sur plusieurs pages, les liens relatifs seront relatifs au fichier dans lequel ils ont été inclus. Si vous avez un extrait de navigation HTML qui va être sur chaque page, alors relatif sera relatif à beaucoup d'endroits différents. La première chose que les gens réalisent lorsqu'ils commencent à créer un modèle est qu'ils ont besoin d'un moyen de gérer les URL.

4. INFORMATIQUE - Ils sont implémentés par votre navigateur (si tout va bien selon RFC). Voir le chapitre 5 dans RFC3986 .

5. OUPS! - Les erreurs ou les fautes de frappe peuvent entraîner des pièges à araignées.

L'évolution des itinéraires

Les développeurs ont cessé d'écrire des URL dans le sens discuté ici. Toutes les demandes concernent le fichier d'index d'un site Web et contiennent une chaîne de requête, également appelée route. L'itinéraire peut être considéré comme une mini URL qui indique à votre application le contenu à générer.

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

Routes Pros:

1. Tous les avantages des URL absolues.
2. Utilisation de n'importe quel caractère dans l'URL.
3. Plus de contrôle (bon pour le référencement).
4. Possibilité de générer des URL par algorithme. Cela permet aux URL d'être configurables. La modification de l'URL est une seule modification dans un seul fichier.
5. Pas besoin de 404 non trouvés. Les itinéraires de secours peuvent afficher une carte du site ou une page d'erreur.
6. Sécurité pratique de l'accès indirect aux fichiers d'application. Les déclarations des gardes peuvent garantir que tout le monde arrive par les voies appropriées.
7. Praticité dans l'approche MVC.

Ma prise

La plupart des gens utiliseront les trois formes dans leurs projets d'une manière ou d'une autre. La clé est de les comprendre et de choisir celle qui convient le mieux à la tâche.

S'il est destiné à être utilisé dans votre site Web, il est préférable d'utiliser une URL relative, comme ceci si vous devez déplacer le site Web vers un autre nom de domaine ou simplement déboguer localement, vous le pouvez.

Jetez un œil à ce que fait stackoverflow (ctrl + U dans Firefox):

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

Dans certains cas, ils utilisent des URL absolues:

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

... mais c'est seulement une meilleure pratique pour améliorer la vitesse. Dans votre cas, il ne semble pas que vous fassiez quelque chose comme ça, donc je ne m'en inquiéterais pas.

Je vais devoir être en désaccord avec la majorité ici.

Je pense que le schéma d'URL relatif est "bien" lorsque vous voulez rapidement mettre quelque chose en place et ne pas sortir des sentiers battus, en particulier si votre projet est petit avec peu de développeurs (ou juste vous-même).

Cependant, une fois que vous commencez à travailler sur de gros systèmes gras où vous changez de domaine et de protocole tout le temps, je pense qu'une approche plus élégante s'impose.

Lorsque vous comparez essentiellement des URL absolues et relatives, Absolute gagne. Pourquoi? Parce que ça ne cassera jamais. Déjà. Une URL absolue est exactement ce qu'elle dit. Le hic, c'est quand vous devez MAINTENIR vos URL absolues.

L'approche faible de la liaison URL absolue est en fait un codage dur de l'URL entière. Pas une bonne idée, et probablement le coupable de la raison pour laquelle les gens les considèrent comme dangereux / mauvais / ennuyeux à entretenir. Une meilleure approche consiste à vous écrire un générateur d'URL facile à utiliser. Ceux-ci sont faciles à écrire et peuvent être incroyablement puissants - détectant automatiquement votre protocole, faciles à configurer (définissez littéralement l'URL une fois pour toute l'application), etc., et il injecte votre domaine tout seul. La bonne chose à ce sujet: vous continuez à coder à l'aide d'URL relatives, et au moment de l'exécution, l'application insère vos URL comme des absolus complets à la volée. Impressionnant.

Étant donné que pratiquement tous les sites modernes utilisent une sorte de back-end dynamique, il est dans l'intérêt dudit site de le faire de cette façon. Les URL absolues font plus que simplement vous assurer où elles pointent - elles peuvent également améliorer les performances de référencement.

Je pourrais ajouter que l'argument selon lequel les URL absolues vont en quelque sorte changer le temps de chargement de la page est un mythe. Si votre domaine pèse plus de quelques octets et que vous utilisez un modem d'accès à distance dans les années 80, bien sûr. Mais ce n'est tout simplement plus le cas. https://stackoverflow.com/ fait 25 octets, alors que le fichier "topbar-sprite.png" qu'ils utilisent pour la zone de navigation du site pèse 9+ ko. Cela signifie que les données URL supplémentaires représentent 0,2% des données chargées par rapport au fichier sprite, et que ce fichier n'est même pas considéré comme un gros succès en termes de performances.

Cette grande image d'arrière-plan pleine page non optimisée est beaucoup plus susceptible de ralentir vos temps de chargement.

Un article intéressant sur les raisons pour lesquelles les URL relatives ne doivent pas être utilisées est ici: http://yoast.com/relative-urls-issues/

Un problème qui peut survenir avec des membres de la famille, par exemple, est que parfois les mappages de serveurs (faites attention aux gros projets foirés) ne correspondent pas aux noms de fichiers et le développeur peut faire une hypothèse sur une URL relative qui n'est tout simplement pas vrai. Je viens de voir ça aujourd'hui sur un projet sur lequel je suis et ça a fait descendre une page entière.

Ou peut-être qu'un développeur a oublié de changer de pointeur et soudainement, Google a indexé tout votre environnement de test. Oups - contenu en double (mauvais pour le référencement!).

Les absolus peuvent être dangereux, mais lorsqu'ils sont utilisés correctement et d'une manière qui ne peut pas casser votre build, ils sont plus fiables. Regardez l'article ci-dessus qui donne un tas de raisons pour lesquelles le générateur d'URL Wordpress est super génial.

:)

Dans la plupart des cas, les URL relatives sont le chemin à parcourir, elles sont portables par nature, ce qui signifie que si vous vouliez soulever votre site et le mettre quelqu'un là où cela fonctionnerait instantanément, réduisant éventuellement les heures de débogage.

Il y a un article assez décent sur les URL absolues et relatives , consultez-le.

Une URL qui commence par le schéma d'URL et la partie spécifique au schéma ( http://,https:// , ftp://, etc.) est une URL absolue.

Toute autre URL est une URL relative et a besoin d'une URL de base à partir de laquelle l'URL relative est résolue (et dépend donc) de l'URL de la ressource dans laquelle la référence est utilisée si elle n'est pas déclarée autrement.

Jetez un œil à RFC 2396 - Annexe C pour des exemples de résolution d'URL relatives.

Disons que vous avez un site www.yourserver.com. Dans le répertoire racine des documents Web, vous avez un sous-répertoire d'images et en ce que vous avez myimage.jpg.

Une URL absolue définit l'emplacement exact du document, par exemple:

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

Une URL relative définit l'emplacement par rapport au répertoire actuel , par exemple, étant donné que vous êtes dans le répertoire Web racine où se trouve votre image:

images/myimage.jpg

(par rapport à ce répertoire racine)

Vous devez toujours utiliser des URL relatives dans la mesure du possible. Si vous déplacez le site vers www.anotherserver.com, vous devrez mettre à jour toutes les URL absolues qui pointaient vers www.yourserver.com, celles relatives continueront de fonctionner telles quelles.

Pour chaque système prenant en charge la résolution URI relative, les URI relatifs et absolus servent le même objectif: le référencement. Et ils peuvent être utilisés de manière interchangeable. Vous pouvez donc décider dans chaque cas différemment. Techniquement, ils fournissent le même référencement.

Pour être précis, avec chaque URI relatif, il existe déjà un URI absolu. Et c'est l'URI de base contre lequel l'URI relatif est résolu. Ainsi, un URI relatif est en fait une fonctionnalité en plus des URI absolus.

Et c'est aussi pourquoi avec des URI relatifs, vous pouvez faire plus comme avec un URI absolu seul - c'est particulièrement important pour les sites Web statiques qui autrement ne pourraient pas être aussi flexibles à maintenir par rapport aux URI absolus.

Ces effets positifs de la résolution relative de l'URI peuvent également être exploités pour le développement d'applications Web dynamiques. Les inflexibilités absolues que les URI introduisent sont également plus faciles à gérer, dans un environnement dynamique, donc pour certains développeurs qui ne sont pas sûrs de la résolution des URI et de la manière de l'implémenter et de la gérer correctement (pas toujours facile), optez souvent pour l'utilisation d'absolu. URI dans une partie dynamique d'un site Web car ils peuvent introduire d'autres fonctionnalités dynamiques (par exemple, une variable de configuration contenant le préfixe URI) afin de contourner l'inflexibilité.

Quel est donc l'avantage d'utiliser des URI absolus? Techniquement, il n'y en a pas, mais je dirais: les URI relatifs sont plus complexes car ils doivent être résolus par rapport à ce que l'on appelle l'URI de base absolu. Même la résolution est strictement définie depuis des années, vous pouvez écraser un client qui a une erreur dans la résolution URI. Comme les URI absolus n'ont besoin d'aucune résolution, l'utilisation d'URI absolus n'a aucun risque de se heurter à un comportement client défectueux avec une résolution d'URI relative. Quel est donc le risque réel? Eh bien, c'est très rare. Je ne connais qu'un navigateur Internet qui avait un problème avec la résolution relative de l'URI. Et ce n'était pas généralement, mais seulement dans un cas très (obscur).

À côté du client HTTP (navigateur), il est peut-être plus complexe pour un auteur de documents ou de code hypertexte. Ici, l'URI absolu a l'avantage d'être plus facile à tester, car vous pouvez simplement le saisir tel quel dans la barre d'adresse de votre navigateur. Cependant, si ce n'est pas seulement votre travail d'une heure, il est le plus souvent plus avantageux pour vous de comprendre la gestion des URI absolus et relatifs afin que vous puissiez réellement exploiter les avantages de la liaison relative.

Je recommanderais chaleureusement des URL relatives pour pointer des bits du même site vers d'autres bits du même site.

N'oubliez pas qu'une modification de HTTPS - même si sur le même site - aura besoin d'une URL absolue.