Comment se fait-il que certaines URL de site n'incluent pas d'extension de fichier?
Je naviguais sur Internet et j'ai remarqué que YouTube, par exemple, contenait une URL comme celle-ci pour désigner une page vidéo: http://www.youtube.com/watch?v=gwS1tGLB0vc.
Mon site utilise une URL similaire à celle-ci pour une page de sujet: http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.
La différence est que, si vous ne l’avez pas déjà remarqué sur youtube, il n’ya pas d’extension de fichier pour leur page de visionnage. Je me pose donc la question suivante: pourquoi certains sites n’utilisent-ils pas les extensions de fichier et à quoi sert-il?
Les extensions de fichier ne sont pas utilisées car les adresses URI (et donc les URL) doivent être indépendantes de l'implémentation. Si vous souhaitez accéder aux adresses de George W. Bush, vous devriez pouvoir accéder à http: //www.whitehouse. gov/presidents/georgewbush/adresses (par exemple). Que les serveurs de la Maison Blanche utilisent PHP ou que Python ou Perl importe peu pour l'utilisateur final, ils ne devraient donc pas le voir. L'utilisateur final ne se soucie pas de la manière dont la page a été générée, car toutes les langues Web affichent le même code HTML, CSS, etc., et visualisent simplement la page dans leur navigateur Web.
La plupart des frameworks Web construisent cette fonctionnalité par défaut, précisément pour cette raison, et cela peut être réalisé indépendamment de la réécriture d'URL dans la plupart des serveurs Web. Cet idéal est codifié dans le Style Guide du W3C, qui est sans aucun doute un grand partisan de cette idée étant si largement acceptée. C'est décrit dans leur guide, "Les URIs cool ne changent pas" , ce qui devrait éclaircir les choses si vous ne comprenez toujours pas bien le raisonnement. Ce document est la déclaration de référence sur la question et la norme de facto pour les cadres.
Il est à noter que les extensions de fichier dont les fichiers finissent par être téléchargés (et parfois, sont parfois toujours utilisées) - http://example.com/song.mp3 ou http://example.com/whitepaper.pdf - car ils sont destinés à être enregistrés sur l'ordinateur de l'utilisateur final, là où les extensions de fichier sont importantes. Les extensions ne sont pas incluses pour les pages simplement display -, ce qui correspond à la plupart des pages.
Ce que vous voyez est un exemple de routage d’URL. Au lieu de pointer sur un fichier spécifique (par exemple, page.php), le serveur utilise une table de routage ou une configuration qui dirige la demande vers un gestionnaire qui restitue le code HTML (ou tout autre élément en fonction du type mime renvoyé). Si vous remarquez, StackOverflow utilise le même mécanisme.
Avoir ou ne pas avoir l'extension n'est pas pertinent. Le navigateur agit sur le type MIME renvoyé par le serveur, pas sur l’extension utilisée dans l’URL.
Quand vous demandez «pourquoi? demandez-vous une raison technique ou une raison de conception? Certaines personnes ont déjà répondu à la technique, je vais donc juste commenter le design.
Fondamentalement, cela se résume à ce que l'URL est un point final. C'est un endroit où les utilisateurs/services doivent se rendre. L'extension est sans importance dans la plupart des cas. Si un utilisateur navigue sur le Web et va sur http://site.com/users il attend une liste d'utilisateurs. Il se fiche que cela ne soit pas écrit en .html ou .php. Et en tant que concepteur utilisant ces extensions n’a pas vraiment de sens. Vous souhaitez que votre application ait un sens, et ces extensions ne fournissent pas vraiment les informations dont l'utilisateur a besoin.
Si vous vouliez créer un service que d'autres applications utiliseraient, vous auriez dû les utiliser plusieurs fois. Ensuite, vous pouvez choisir d’utiliser une extension pour indiquer le type de données que l’on peut s’attendre à récupérer (.json, .xml, etc.). Il y a des gens qui travaillent sur les directives de conception et les spécifications pour ce genre de choses, mais il est tôt
Fondamentalement, ces extensions sont utilisées car c'est ainsi que les serveurs/clients Web fonctionnaient par défaut. Au fur et à mesure que le développement Web a mûri, nous avons commencé à traiter les URL de manière plus professionnelle et avons essayé de leur donner un sens pour les personnes qui les lisaient/les utilisaient.
Bien que les extensions n'importent pas au navigateur, qui utilise uniquement les en-têtes qui lui sont transmis pour déterminer ce qu'il faut afficher et comment les afficher, il est probable qu'elles do comptent sur le serveur. Par exemple, un interpréteur php et un interpréteur Ruby peuvent être installés sur votre boîte, mais votre serveur Web contient des fichiers de configuration permettant de mapper les extensions de fichier aux types MIME. Par exemple, dans php5.conf d'Apache:
AddType application/x-httpd-php .php .phtml .php3
ce qui indique à Apache que les fichiers se terminant par .php, .phtml et .php3 doivent être reconnus comme étant des fichiers PHP.
Cependant, étant donné que les extensions ne signifient rien pour le client, les URL sont souvent "plus agréables" sans elles. Pour ce faire, des technologies telles que mod_rewrite d'Apache peuvent être utilisées pour "réécrire" les URLs client-land afin qu'elles aient une signification sur le serveur.
Par exemple, vous pouvez configurer des règles mod_rewrite pour réécrire une URL telle que http://yourblog.com/article/the-article-you-wrote (plus jolie et plus simple à saisir et à mémoriser) sur http://yourblog.com/articles.php?title=the-article-you-wrote, qu'Apache peut utiliser pour acheminer correctement la demande vers votre script PHP.
L'URL doit être correctement considéré comme faisant partie de l'interface utilisateur. En tant que tel, il devrait être conçu pour transmettre des informations sur l'emplacement de l'utilisateur sur le site et sur la structure du site.
Une URL telle que:
mysite.com/sport/soccer/brazil_wins_worldcup
indique beaucoup à l'utilisateur la structure du site et son emplacement actuel. En revanche:
mysite.com/article.php?cateogry=12&articleid=371
est inutile, au lieu de cela, il expose des détails d'implémentation non pertinents, tels que la langue utilisée pour créer le site et l'identifiant de cet article (probablement stocké dans une base de données sous cet identifiant)
En plus de cet argument moral (ne soumettez pas l'utilisateur à des détails d'implémentation non pertinents), il contribue également à rendre le site à l'épreuve du temps. Parce que si vous n’exposiez jamais la langue de votre choix, vous pourrez passer ultérieurement à Ruby ou à Python, sans que tous les liens du monde pointant vers vous ne soient désormais des 404.
Les URL de conception doivent avoir un sens pour les utilisateurs, et être à l'épreuve du temps.
La clé est le champ Content-Type de l'en-tête de réponse HTTP. Quelque chose comme ca:
HTTP 200 OK
Content-Type: video/flv
Content-Length: 102345
DATA-DATA-DATA-DATA-DATA-DATA-....
Voir également:
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
Plus de détails: http://en.wikipedia.org/wiki/MIME
Les extensions de fichier ne sont d'aucune utilité sur Internet. Le navigateur ne s’intéresse pas à l’extension du fichier. Vous pouvez servir un fichier CSS au format .avi. Alors, pourquoi ne pas simplement laisser tomber? Cela permet d'avoir des URL plus courtes.
De plus, la "réécriture" d'une URL permet d'obtenir des URL plus lisibles. Vous ne comprenez peut-être pas /categories.php?id=455 mais /455-some-category.
Si vous souhaitez le faire vous-même et que vous utilisez Apache, consultez mod_rewrite.
Il y a beaucoup de réponses possibles à cela. C'est la façon dont votre ou vos serveurs d'applications Web sont configurés qui entraîne l'interprétation de votre navigateur Web. Il peut arriver que vous utilisiez la réécriture ou le routage d'URL et, comme d'autres l'ont dit, les gestionnaires que vous fournissez pour les URL ou les extensions demandées.
Je pourrais avoir une URL du type " http://cory.com/this/really/doesnt/exist " et le faire pointer en direction de " http://cory.com/this.does.exist .123 "si je voulais.
Le comportement normal d'un serveur Web consiste à mapper le chemin d'accès de l'URI demandé sur un fichier quelque part dans le répertoire racine du document. Donc, http://example.com/foo/bar est simplement mappé sur /path/do/document/root/foo/bar. De plus, le serveur Web doit savoir comment gérer un fichier. Cela se fait souvent par l'extension de nom de fichier. Ainsi, les fichiers portant l'extension .php sont gérés par l'interpréteur PHP.
Outre ce comportement normal, la plupart des serveurs Web possèdent des fonctionnalités qui permettent de modifier le mappage (c'est-à-dire la réécriture d'URL ) et la manière dont un fichier sans extension de nom de fichier est traité.
Dans le cas du serveur Web Apache, le premier peut être fait avec mod_rewrite :
RewriteEngine on
RewriteRule ^/watch$ /watch.php
Et ce dernier peut être fait avec mod_mime :
<File watch>
ForceType application/x-httpd-php
</File>
(Ok, en fait, ce n'est pas une fonctionnalité mod_mime, mais une fonctionnalité core .)
Règle: les extensions de fichier ne doivent pas être incluses dans les URI
Sur le Web, le caractère point (.) Est couramment utilisé pour séparer les parties nom de fichier et extension D’un URI. Une API REST ne doit pas inclure d’extensions de fichiers artificielles Dans les URI pour indiquer le format du corps de l’entité du message. Au lieu de cela, ils doivent s’appuyer sur Le type de support, indiqué par l’en-tête Content-Type, pour déterminer comment Traiter le contenu du corps.
(1) http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2) http: //api.college.restapi. org/étudiants/3248234/transcriptions/2005/automne
(1) Les extensions de fichier ne doivent pas être utilisées pour indiquer la préférence de format. (2) Les clients de l'API REST doivent être encouragés à utiliser le mécanisme de sélection de format fourni par HTTP , L'en-tête de demande Accepter. ] références: design REST livre de règles api
en dessous, ce que j’utilise dans mon fichier .htaccess pour que l’url fonctionne toujours correctement sans l’extension HTML ou PHP.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
signifie que si le fichier portant le nom spécifié dans le navigateur ne correspond pas au répertoire (-d) ou aux fichiers (-f) de votre serveur Web, la règle de réécriture ci-dessous s'affiche.
RewriteRule ^(.*)$ $1.html
je ne suis pas sûr de savoir comment fonctionnent les éléments ci-dessous, mais je pense qu'après avoir réécrit avec html et s'il ne correspond toujours pas, réécrire avec php
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php
s'il ne correspond toujours pas, il affichera la page 404.
vous pouvez également rediriger 404 avec le code ci-dessous dans .htaccess
ErrorDocument 404 /404.html
l'importance est que le code fonctionne pour mon site.
ceux-ci n'ont pas besoin de l'extension de fichier.