Почему некоторые URL-адреса сайтов не включают расширение файла?

Расширения файлов не используются из-за идеи, что URI (и, следовательно, URL-адреса) не должны зависеть от реализации — если вы хотите получить доступ к информации CDC о безопасности пищевых продуктов, вы должны иметь возможность перейти на https://www.cdc.gov/foodsafety (например). Для конечного пользователя не имеет значения, используют ли серверы CDC PHP, Python или Perl, поэтому они не должны этого видеть. Конечного пользователя не волнует, как была сгенерирована страница, потому что все языки, обслуживающие веб-страницу, выводят один и тот же HTML, CSS и т.п., а пользователь просто просматривает страницу в своем веб-браузере.

Большинство веб-фреймворков встраивают эту функциональность по умолчанию именно по этой причине, и ее можно реализовать независимо от перезаписи URL-адресов на большинстве веб-серверов. Этот идеал кодифицирован в Руководстве по стилю W3C, которое, несомненно, является большим сторонником этой идеи, получившей столь широкое признание. Это описано в их руководстве Крутые URI не меняются, которое должно очистить вещи вверх, если вы все еще не совсем понимаете рассуждения здесь. Этот документ является основным заявлением по этому вопросу и стандартом де-факто для фреймворков.

Стоит отметить, что обычно файлы, которые в конечном итоге загружаются (а иногда и файлы данных, используемые в AJAX), по-прежнему сохраняют свои расширения файлов - http://example.com/song.mp3 или http://example.com/whitepaper.pdf, потому что они предназначены для сохранения на компьютере конечного пользователя, где расширения файлов имеют значение. Расширения не включаются для страниц, которые просто отображаются — а это большинство страниц.

Постскриптум: примерная страница, на которую изначально ссылался этот ответ, в какой-то момент перестала существовать, потому что иногда URI меняются, несмотря на лучшие практики. Я заменил его страницей безопасности пищевых продуктов CDC, которая существовала в той или иной форме для по крайней мере 20 лет назад. Несомненно, множество различных технологий обслуживали этот контент на протяжении многих лет, всегда делая это по одному и тому же URL-адресу.

То, что вы видите, является примером маршрутизации URL-адресов. Вместо того, чтобы указывать на конкретный файл (например, page.php), сервер использует таблицу маршрутизации или конфигурацию, которая направляет запрос обработчику, который фактически отображает html (или что-либо еще, в зависимости от возвращаемого типа mime). Если вы заметили, StackOverflow использует тот же механизм.

Наличие или отсутствие расширения значения не имеет. Браузер действует на основе типа MIME, возвращаемого сервером, а не на любом расширении, используемом в URL-адресе.

Когда вы спрашиваете «Почему?» вы спрашиваете по технической причине или по причине дизайна? Некоторые люди уже ответили на технические вопросы, поэтому я просто прокомментирую дизайн.

В основном это сводится к тому, что URL-адрес является конечной точкой. Это то место, куда должны попасть пользователи/службы. Расширение в большинстве случаев не имеет значения. Если пользователь просматривает Интернет и переходит на http://site.com/users, он ожидает список пользователи. Его не волнует, что это не .html или .php. И использование этих расширений как дизайнера не имеет особого смысла. Вы хотите, чтобы ваше приложение имело смысл, а эти расширения на самом деле не дают никакой информации, которая нужна пользователю.

Времена, когда вы хотели бы их использовать, были, если бы вы создавали службу, которую использовали бы другие приложения. Затем вы можете использовать расширение для обозначения того, какие данные можно ожидать получить обратно (.json, .xml и т. д.). Есть люди, работающие над рекомендациями по дизайну и спецификациями для этого материала, но пока все рано.

В основном эти расширения используются, потому что так работают веб-серверы/клиенты по умолчанию. По мере развития веб-разработки мы стали более профессионально относиться к URL-адресам и пытались сделать их понятными для людей, которые их читают/используют.

Хотя расширения не имеют значения для браузера, который просто использует переданные ему заголовки, чтобы определить, что отображать и как это отображать, скорее всего, они имеют значение на сервере. Например, на вашем компьютере могут быть установлены как интерпретатор php, так и интерпретатор ruby, но на вашем веб-сервере есть файлы конфигурации для сопоставления расширений файлов с типами MIME. Например, из php5.conf Apache:

  AddType application/x-httpd-php .php .phtml .php3

который сообщает Apache, что файлы, оканчивающиеся на .php, .phtml и .php3, должны распознаваться как файлы PHP.

Однако, поскольку расширения ничего не значат для клиента, URL-адреса часто выглядят «красивее» без них. Для этого можно использовать такие технологии, как mod_rewrite Apache. «перепишите» URL-адреса клиентской части, чтобы они имели смысл на сервере.

Например, вы можете настроить mod_rewrite правила, чтобы переписать URL-адрес типа http://yourblog.com/article/the-article-you-wrote (который выглядит лучше, его проще набирать и запоминать) на http://yourblog.com/articles.php?title=the-article-you-wrote, который Apache может использовать для правильной маршрутизации запроса к вашему PHP-скрипту.

Ключом является поле Content-Type заголовка ответа HTTP. Что-то такое:

HTTP 200 OK
Content-Type: video/flv
Content-Length: 102345

DATA-DATA-DATA-DATA-DATA-DATA-....

Смотрите также:

Content-Disposition: attachment; filename=genome.jpeg;
     modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

Дополнительные сведения: http://en.wikipedia.org/wiki/MIME

Ну, расширения файлов бесполезны в Интернете. Браузеру все равно, какое расширение у файла. Вы можете использовать файл CSS как .avi. Так почему бы просто не оставить это? Это позволяет использовать более короткие URL-адреса.

Кроме того, «переписывание» URL-адреса позволяет сделать его более читаемым. Вы можете не понимать /categories.php?id=455, но понимаете /455-some-category.

Если вы хотите сделать это самостоятельно и используете Apache, взгляните на mod_rewrite.

URL-адрес следует правильно рассматривать как часть пользовательского интерфейса. Таким образом, он должен быть предназначен для передачи информации о том, где находится пользователь на сайте, и о структуре сайта.

URL-адрес, такой как:

mysite.com/sport/soccer/brazil_wins_worldcup

рассказывает пользователю многое о структуре сайта и о том, где он сейчас находится. В отличие:

mysite.com/article.php?cateogry=12&articleid=371

бесполезен, вместо этого он раскрывает нерелевантные детали реализации, например, какой язык используется для создания сайта и каков идентификатор этой статьи (вероятно, хранится в базе данных под этим идентификатором)

В дополнение к этому эстетическому аргументу (не показывайте пользователю нерелевантные детали реализации) это также помогает сделать сайт перспективным. Потому что, если вы никогда не раскрывали выбранный вами язык с самого начала, вы можете позже перейти на Ruby или Python, без каждой ссылки в мире, которая указывает на вас, теперь это 404.

Создавайте URL-адреса так, чтобы они были понятны пользователям и и ориентированы на будущее.

На это есть много возможных ответов. То, как настроены ваши серверы веб-приложений, приводит к тому, что интерпретирует ваш веб-браузер. Могут быть ситуации, когда вы используете перезапись или маршрутизацию URL-адресов, и, как уже говорили другие, какие обработчики вы предоставляете для запрошенных URL-адресов или расширений.

У меня мог бы быть такой URL-адрес, как "http://cory.com/this/really/doesnt/exist" и действительно указывать на "http://cory.com/this.does.exist.123", если бы я захотел.

Обычное поведение веб-сервера заключается в сопоставлении запрошенного пути URI с файлом где-то в корневом каталоге документа. Таким образом, http://example.com/foo/bar просто отображается на /path/do/document/root/foo/bar. Кроме того, веб-сервер должен знать, как обращаться с файлом. Это часто делается с помощью расширения имени файла. Таким образом, файлы с расширением имени файла .php обрабатываются интерпретатором PHP.

Теперь, помимо этого нормального поведения, большинство веб-серверов имеют функции, которые позволяют изменять как сопоставление (например, перезапись URL) и способ обработки файла без расширения имени файла.

В случае веб-сервера Apache первое можно сделать с помощью mod_rewrite:

RewriteEngine on
RewriteRule ^/watch$ /watch.php

И последнее можно сделать с помощью mod_mime:

<File watch>
    ForceType application/x-httpd-php
</File>

(Хорошо, на самом деле это не функция mod_mime, а основная функция. )

Правило: расширения файлов не должны включаться в URI

В Интернете символ точки (.) обычно используется для разделения частей имени файла и расширения URI. REST API не должен включать искусственные расширения файлов в URI для указания формата тела объекта сообщения. Вместо этого они должны полагаться на тип носителя, который сообщается через заголовок Content-Type, чтобы определить, как обрабатывать содержимое тела.

(1)http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2)http://api.college.restapi.org/students/3248234/transcripts/2005/fall

(1) Расширения файлов не должны использоваться для указания предпочтения формата. (2) Клиентам REST API следует рекомендовать использовать предоставленный HTTP механизм выбора формата, заголовок запроса Accept. ссылки: дизайн REST API Rulebook

ниже то, что я использую в своем .htaccess, чтобы URL-адрес по-прежнему работал правильно без расширения HTML или PHP.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f

означает, что если файл с указанным именем в браузере не совпадает с каталогом (-d) или файлами (-f) на вашем веб-сервере, то перепишите правило ниже

RewriteRule ^(.*)$ $1.html

я не уверен, как работает ниже, но я думаю, что после того, как он перепишет с помощью html, и если он все еще не соответствует ему, перепишите с помощью php

RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php

если он все еще не соответствует, будет показана страница 404.

вы также можете перенаправить 404 с кодом ниже в .htaccess

ErrorDocument 404 /404.html

важно то, что код работает для моего сайта.

http://mintnet.net/services

http://php.mintnet.net/home

им не нужно расширение файла.

«www.youtube.com/watch» — это каталог YouTube. Таким образом, в основном это может быть написано как «www.youtube.com/watch/» с косой чертой в конце.