URL absolues vs relatives
J'aimerais 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-il préférable d'utiliser?
En règle générale, il est recommandé 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 travailler sur localhost, ainsi que sur votre domaine public, sans modifications.
Devrais-je utiliser des URL absolues ou relatives?
Si vous entendez par URL absolues, vous entendez des URL comprenant un schéma (par exemple, http/https) et le nom d’hôte (par exemple, votre domaine.com), ne le faites jamais (pour les ressources locales) car il sera difficile à maintenir et à déboguer.
Supposons que vous ayez utilisé l'URL absolue partout dans votre code, comme _<img src="http://yourdomain.com/images/example.png">_. Maintenant, que va-t-il se passer quand vous allez:
- basculer vers un autre schéma (par exemple, http -> https)
- changer de nom de domaine (test.votredomaine.com -> votredomaine.com)
Dans le premier exemple, vous obtiendrez des avertissements concernant le contenu non sécurisé demandé sur la page. Parce que toutes vos URL sont codées en dur pour utiliser http (: //votredomaine.com/images/exemple.png). Et lorsque vous exécutez vos pages sur http, le navigateur s'attend à ce que toutes les ressources soient chargées sur https afin d'éviter toute fuite d'informations.
Dans le deuxième exemple, lorsque vous mettez votre site en direct à partir de l'environnement de test, cela signifie que toutes les ressources pointent toujours sur votre domaine de test plutôt que sur votre domaine actif.
Donc, pour répondre à votre question sur l’utilisation des URL absolues ou relatives: utilisez toujours des URL relatives (pour les ressources locales).
Quelle est la différence entre les différentes URL?
Premièrement, regardons quelle différence nous pouvons utiliser:
- _
http://yourdomain.com/images/example.png_ - _
//yourdomain.com/images/example.png_ - _
/images/example.png_ - _
images/example.png_
À quelles ressources ces URL tentent-elles d'accéder sur le serveur?
Dans les exemples ci-dessous, je suppose que le site Web est exécuté à partir de l'emplacement suivant sur le serveur _/var/www/mywebsite_.
http://yourdomain.com/images/example.png
L'URL (absolue) ci-dessus tente d'accéder à la ressource _/var/www/website/images/example.png_. Ce type d’URL est quelque chose que vous voudriez toujours éviter de demander des ressources à votre site Web pour les raisons susmentionnées. Cependant, il a sa place. Par exemple, si vous avez un site Web _http://yourdomain.com_ et que vous souhaitez demander une ressource à partir d'un domaine externe via http, 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 et doit presque toujours être utilisée lors de l’inclusion de ressources externes (images, javascripts, etc.).
Ce type d'URL utilise le schéma actuel de la page sur laquelle il se trouve. Cela signifie que vous êtes sur la page _http://yourdomain.com_ et que sur cette page se trouve une balise d'image _<img src="//yourdomain.com/images/example.png">_, l'URL de l'image serait résolue en _http://yourdomain.com/images/example.png_.
Si vous vous trouviez sur la page _http**s**://yourdomain.com_ et que cette page contient une balise d'image _<img src="//yourdomain.com/images/example.png">_, l'URL de l'image sera résolue en _https://yourdomain.com/images/example.png_.
Cela empêche le chargement de ressources via https lorsqu'il n'est pas utilisé et garantit automatiquement que la ressource est demandée via https lorsqu'elle est requise .
L'URL ci-dessus est résolue de la même manière côté serveur que l'URL précédente:
L'URL (absolue) ci-dessus tente d'accéder à la ressource _
/var/www/website/images/example.png_.
/images/example.png
Pour les ressources locales, c'est la méthode privilégiée pour 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 avez _<img src="/images/example.png">_, il sera toujours résolu en _/var/www/mywebsite/images/example.png_.
Si, à un moment donné, vous décidez de changer de domaine, cela fonctionnera car il est relatif.
images/example.png
C'est aussi une URL relative, bien que légèrement différente de la précédente. Cette URL est relative au chemin actuel. Cela signifie que le problème sera résolu 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.com_ et que vous utilisez _<img src="images/example.png">_, le serveur le résout en _/var/www/mywebsite/images/example.png_ comme prévu, mais lorsque vous êtes sur la page _http://yourdomain.com/some/path_ et vous utilisez exactement la même balise d’image, elle se transformera soudainement en _/var/www/mywebsite/some/path/images/example.png_.
Quand utiliser quoi?
Lorsque vous demandez des ressources externes, vous souhaitez probablement utiliser une URL relative au schéma (sauf si vous souhaitez forcer un schéma différent) et lorsque vous utilisez 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
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 précédant la partie "chemin". En d'autres termes, elle inclut le schéma (le http dans http://foo/bar/baz) et le nom d'hôte (le foo dans http://foo/bar/baz) (et éventuellement port, userinfo et port).
Les URL relatives commencent par un chemin.
Les URL absolues sont, bien, absolues: l'emplacement de la ressource peut être résolu en regardant uniquement l'URL elle-même. Une URL relative est en quelque sorte incomplète: pour la résoudre, vous avez besoin du schéma et du nom d'hôte, qui sont généralement extraits du contexte actuel. Par exemple, dans une page Web à l'adresse
http://myhost/mypath/myresource1.html
vous pouvez mettre un lien comme si
<a href="pages/page1">click me</a>
Dans l'attribut href du lien, une URL relative est utilisée et, si vous cliquez dessus, vous devez la résoudre pour pouvoir 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 principal de ceux-ci soient pris et ajoutés au début à pages/page1, donnant
http://myhost/mypath/pages/page1
Si le lien aurait été:
<a href="/pages/page1">click me</a>
(notez le / apparaissant au début de l’URL) alors il aurait été résolu comme
http://myhost/pages/page1
parce que le / initial indique la racine de l'hôte.
Dans une application Web, je vous conseillerais d'utiliser des URL relatives pour toutes les ressources appartenant à votre application. Ainsi, si vous modifiez l'emplacement des pages, tout continuera à fonctionner. Toutes les ressources externes (qu'il s'agisse de pages complètement externes à votre application, mais également de contenu statique que vous transmettez via un réseau de diffusion de contenu) doivent toujours être orientées vers des URL absolues: sinon, il n'y a aucun moyen de les localiser, car elles résider sur un autre serveur.
Supposons que nous créons un sous-site Web 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 les URL relatives paraissent plus courtes que les absolues, elles sont toutefois préférables, car un lien peut être utilisé sans modification sur n’importe quelle page du site.
Cas intermédiaires
Nous avons considéré deux cas extrêmes: les URL "absolument" absolues et les URL "absolument" relatives. Mais tout est relatif dans ce monde. Ceci s'applique également aux URL. Chaque fois que vous parlez d'URL absolue, vous devez toujours spécifier relative à 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 cette URL. Cependant, on considère généralement 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 à remplacer en masse le 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/"
Maintenant, vous pouvez déplacer votre site non seulement vers n'importe quel domaine, mais dans n'importe quel sous-dossier. Gardez simplement à l'esprit que, bien que les URL semblent relatives, elles sont en réalité 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" et non pas 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 gérées à un niveau inférieur, j'irais même jusqu'à dire que les développeurs pourraient passer toute leur vie sans écrire une seule URL à la main.
Absolu
Les 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:
Contrôle - Le sous-domaine et le protocole peuvent être contrôlés. Les personnes qui entrent par un sous-domaine obscur seront acheminées vers le sous-domaine approprié. Vous pouvez basculer entre sécurisé et non sécurisé, le cas échéant.
Configurable - Les développeurs aiment les choses absolues. Vous pouvez concevoir des algorithmes ordonné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.
Clairvoyance - Vous pouvez rechercher les personnes qui grattent votre site ou éventuellement récupérer des liens externes supplémentaires.
Racine Relative
Les URL relatives racines relient votre code à l'URL de base. Cela peut être surmonté avec des URL dynamiques et/ou balises de base .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Racine Relative Pour:
- Configurable - La balise de base les rend relatives à toute racine choisie, facilitant ainsi le changement de domaine et la mise en œuvre de modèles.
relatif
Les URL relatives lient votre code à la structure de répertoires. Il n'y a aucun moyen de surmonter cela. Les URL relatives ne sont utiles que dans les systèmes de fichiers pour parcourir des répertoires ou comme raccourci pour une tâche secondaire.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
inconvénients relatifs:
DÉROUTANT - Combien de points s'agit-il? combien de dossiers est-ce? Où est le fichier? Pourquoi ça ne marche pas?
MAINTENANCE - Si un fichier est déplacé par inadvertance, les liens cessent d'être chargés, les liens envoient l'utilisateur aux mauvaises pages, les données de formulaire peuvent être envoyées à la mauvaise page. Si un fichier DOIT être déplacé, toutes les ressources qui vont quitter le chargement et tous les liens incorrects doivent être mis à jour.
NE PAS ÉCHELLE - 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 elles ont été incluses. Si vous avez un extrait de navigation de HTML qui sera 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, c'est qu'ils ont besoin d'un moyen de gérer les URL.
CALCULÉS - Ils sont implémentés par votre navigateur (heureusement selon RFC). Voir le chapitre 5 dans RFC3986 .
OOPS! - Des erreurs ou des fautes de frappe peuvent entraîner des interruptions d'araignées.
L'évolution des routes
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, ou 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:
- Tous les avantages des urls absolues.
- Utilisation de n'importe quel caractère dans l'URL.
- Plus de contrôle (bon pour le référencement).
- Capacité à générer des URL de manière algorithmique. Cela permet aux URL d'être configurables. La modification de l'URL est une modification unique dans un fichier unique.
- Pas besoin de 404 non trouvés. Les itinéraires de secours peuvent afficher un plan du site ou une page d'erreur.
- 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 canaux appropriés.
- Pratique 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 celui qui convient le mieux à la tâche.
Je vais devoir être en désaccord avec la majorité ici.
Je pense que le schéma d'URL relatif est "correct" lorsque vous souhaitez rapidement mettre en place quelque chose 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 dans lesquels vous changez de domaine et de protocole à tout moment, je pense qu'une approche plus élégante est de mise.
Lorsque vous comparez 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 problème est que vous devez MAINTENIR vos URL absolues.
L’approche faible de la liaison absolue d’URL consiste en fait à coder de manière rigide l’URL entière. Ce n’est pas une bonne idée, et probablement le coupable de la raison pour laquelle les gens les considèrent comme dangereuses/mauvaises/ennuyeuses à maintenir. Une meilleure approche consiste à écrire vous-même un générateur d’URL facile à utiliser. Celles-ci sont faciles à écrire et peuvent être incroyablement puissantes- détectant automatiquement votre protocole, faciles à configurer (définissez littéralement l'URL une fois pour l'application entière), etc, et il injecte votre domaine tout seul. La bonne chose à ce sujet: vous continuez à coder en utilisant des URL relatives et, au moment de l’exécution, l’application insère vos URL de manière absolue à 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 de ce site de le faire de cette façon. Les URL absolues ne font pas que vous indiquer avec certitude où elles pointent, elles peuvent également améliorer les performances de référencement.
J'ajouterais que l'argument selon lequel les URL absolues vont en quelque sorte modifier le temps de chargement de la page est un mythe. Si votre domaine pèse plus de quelques octets et que vous êtes connecté à un modem par numérotation dans les années 1980, bien sûr. Mais ce n'est plus le cas. https://stackoverflow.com/ = 25 octets, alors que le fichier "topbar-Sprite.png" utilisé pour la zone de navigation du site pèse plus de 9 ko. Cela signifie que les données d'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 problème de performances.
Cette grande image d'arrière-plan pleine page non optimisée est beaucoup plus susceptible de ralentir vos temps de chargement.
Voici un article intéressant sur la raison pour laquelle les URL relatives ne doivent pas être utilisées: http://yoast.com/relative-urls-issues/
Un problème qui peut survenir avec les membres de la famille, par exemple, est que, parfois, les mappages de serveur (attention, sur les gros projets gâchés) ne s'alignent pas sur les noms de fichiers et le développeur peut faire l'hypothèse d'une URL relative qui n'est tout simplement pas. vrai. Je viens de voir cela aujourd'hui sur un projet sur lequel je suis et cela a ramené une page entière.
Ou peut-être un développeur a-t-il oublié de changer de pointeur et tout à coup, Google a indexé l'ensemble de votre environnement de test. Whoops- dupliquer le contenu (mauvais pour le référencement!).
Les absolus peuvent être dangereux, mais s’ils sont utilisés correctement et d’une manière qui ne ne peut pas briser votre construction , ils se sont avérés plus fiables. Regardez l'article ci-dessus qui donne une foule de raisons pour lesquelles le générateur d'URL Wordpress est génial.
:)
S'il est destiné à être utilisé sur votre site Web, il est préférable d'utiliser une URL relative, par exemple si vous devez déplacer le site Web vers un autre nom de domaine ou simplement déboguer localement, vous pouvez le faire.
Jetez un coup d’œ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 ceci est seulement une pratique recommandée pour améliorer la vitesse. Dans votre cas, il ne semble pas que vous agissiez de la sorte, alors je ne m'inquiéterais pas pour ça.
Dans la plupart des cas, les URL relatives sont le chemin à parcourir. Elles sont par nature portables, ce qui signifie que si vous souhaitez améliorer votre site et le placer à un autre endroit, cela fonctionnerait instantanément, ce qui réduirait peut-être des heures de débogage.
Il y a un assez décent article sur les URL absolues vs relatives , consultez-le.
Une URL commençant par le schéma d'URL et sa partie spécifique (http://, https://, ftp://, etc.) est une URL absolue.
Toute autre URL est une URL relative et nécessite une URL de base à partir de laquelle l'URL relative est résolue (et dépend donc), c'est-à-dire l'URL de la ressource utilisée par la référence, si elle n'est pas déclarée autrement.
Jetez un œil à RFC 2396 - Annexe C pour consulter des exemples de résolution d'URL relatives.
Disons que vous avez un site www.votreserveur.com. Dans le répertoire racine des documents Web, vous avez un sous-répertoire d'images et le fichier 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, si vous êtes dans le répertoire Web racine de 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 adresses URL absolues pointées vers www.votreserver.com. Les adresses relatives continueront à fonctionner telles quelles.
Pour chaque système prenant en charge la résolution d'URI relative, les adresses URI relatives et absolues servent le même objectif: le référencement. Et ils peuvent être utilisés de manière interchangeable. Ainsi, vous pourriez 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. Donc, un URI relatif est en fait une fonctionnalité au-dessus des URI absolus.
Et c’est aussi pourquoi, avec les URI relatifs, vous pouvez faire plus comme avec un seul URI absolu - ceci est particulièrement important pour les sites Web statiques qui ne pourraient autrement pas être aussi flexibles à maintenir que les URI absolus.
Ces effets positifs de la résolution relative des adresses URI peuvent également être exploités pour le développement d'applications Web dynamiques. La rigidité des URIs absolus introduits est également plus facile à gérer dans un environnement dynamique. Ainsi, pour certains développeurs qui ne connaissent pas bien la résolution des adresses URI, ni comment la mettre en œuvre et la gérer correctement (même si cela est toujours facile), optent souvent pour l’utilisation absolue. Les 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 de l'URI) afin de contourner l'inflexibilité.
Alors, quel est 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 qu'on appelle l'URI de base absolu. Même si la résolution est strictement définie depuis des années, vous pouvez rencontrer un client qui a une erreur dans la résolution de l'URI. Les adresses URI absolues ne nécessitant aucune résolution, leur utilisation ne risque pas de donner lieu à un comportement client défectueux avec une résolution d'URI relative. Alors, quel est le risque réel? Eh bien, c'est très rare. Je ne connais qu'un navigateur Internet qui a eu un problème de résolution relative d'URI. Et ce n’était pas généralement, mais seulement dans un cas très (obscur).
En plus du client HTTP (navigateur), il est peut-être plus complexe pour un auteur de document hypertexte ou de code. Ici, l'URI absolu présente l'avantage d'être plus facile à tester, car vous pouvez simplement le saisir tel quel dans la barre d'adresse de votre navigateur. Toutefois, s'il ne s'agit pas uniquement d'une heure de travail, il est généralement plus avantageux pour vous de comprendre réellement le traitement des adresses URI absolues et relatives afin d'exploiter au mieux les avantages de la liaison relative.