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



Я просматривал интернет и заметил, что YouTube, например, содержит URL-адрес, подобный этому, чтобы обозначить страницу видео: http://www.youtube.com/watch?v=gwS1tGLB0vc.



Мой сайт использует URL-адрес, подобный этому для страницы темы: http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.



Разница в том, что если вы еще не заметили, что на youtube нет расширения файла для их страницы просмотра, поэтому мне интересно, почему некоторые сайты не используют расширения файлов и для чего они служат?

1297   13  

13 ответов:

Расширения файлов не используются из-за идеи, что URI (и, следовательно, URL) должны быть независимы от реализации - если вы хотите получить доступ к адресам Джорджа Буша-младшего, вы должны иметь возможность перейти к http://www.whitehouse.gov/presidents/georgewbush/addresses (например). Используют ли серверы Белого дома PHP, Python или Perl, не имеет значения для конечного пользователя, поэтому они не должны его видеть. Конечный пользователь не заботится о том, как была создана страница, потому что все веб-языки выводите один и тот же HTML, CSS и тому подобное, и они просто просматривают страницу в своем веб-браузере.

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

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

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

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

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

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

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

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

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

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

Который говорит Apache, что файлы заканчиваются .РНР, .phtml И.php3 должен быть распознается как PHP-файлы.

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

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

Ключ - это поле заголовка HTTP-ответа Content-Type. Что-то вроде этого:

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-файл как .Ави. Так почему бы просто не оставить все как есть? Это позволяет использовать более короткие URL-адреса.

Кроме того," переписывание " 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, а функция core.)

Правило: расширения файлов не должны включаться в 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. ссылки: design 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/" с окончанием косой черты вперед.

Comments

    Ничего не найдено.