Я просматривал интернет и заметил, что YouTube, например, содержит такой URL, чтобы обозначить видеостраницу: http://www.youtube.com/watch?v=gwS1tGLB0vc.
Мой сайт использует такой URL-адрес для страницы темы: http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.
Разница в том, что, если вы еще не заметили, что на youtube нет расширения файла для их часовой страницы, так что мне интересно, почему некоторые сайты не используют расширения файлов и что они используют?
Расширения файлов не используются из-за идеи, что URI (и, следовательно, URL) должны быть независимы от реализации - если вы хотите получить доступ к адресам Джорджа У. Буша, вы должны иметь возможность перейти к http://www.whitehouse.gov/presidents/georgewbush/addresses (например). Независимо от того, используют ли серверы Белого дома PHP или Python или Perl, конечный пользователь не имеет значения, поэтому они не должны его видеть. Конечный пользователь не заботится о том, как была создана страница, потому что все веб-языки выдают один и тот же HTML, CSS и т.п., И они просто просматривают страницу в своем веб-браузере.
Большинство веб-фреймворков создают эту функцию по умолчанию именно по этой причине, и ее можно выполнить независимо от перезаписи URL-адресов в большинстве веб-серверов. Этот идеал кодифицирован в Руководстве по стилю W3C, который, несомненно, является большим сторонником в этой идее, столь широко принятой. Он изложил в своем руководстве "Cool URIs not Change" , что должно прояснить ситуацию, если вы все еще не совсем понимаете рассуждения здесь, Этот документ является вступительным выражением по этой проблеме и стандартом де-факто для фреймворков.
Стоит отметить, что обычно файлы, которые в конечном итоге загружаются (а иногда и файлы данных, используемые в AJAX), будут по-прежнему иметь свои расширения файлов - http://example.com/song.mp3 или http://example.com/whitepaper.pdf - потому что они предназначены для сохранения на компьютере конечного пользователя, где важны расширения файлов. Расширения не включены для страниц, которые просто отображаются - это большинство страниц.
То, что вы видите, является примером маршрутизации URL. Вместо указания на конкретный файл (например, page.php) сервер использует таблицу или конфигурацию маршрутизации, которая направляет запрос обработчику, который фактически отображает html (или что-либо еще в зависимости от возвращаемого типа mime). Если вы заметили, StackOverflow использует тот же механизм.
Наличие или отсутствие расширения не имеет значения. Браузер работает с типом MIME, возвращаемым сервером, а не с расширением, используемым в URL-адресе.
Когда вы спрашиваете "Почему?" вы просите техническую причину или конструктивную причину? Некоторые люди уже ответили на технические вопросы, поэтому я просто прокомментирую дизайн.
В основном это сводится к тому, что URL-адрес является конечной точкой. Это место, к которому должны обратиться пользователи/службы. В большинстве случаев расширение не имеет значения. Если пользователь просматривает веб-страницы и переходит на http://site.com/users, он ожидает список пользователей. Ему все равно, что он не говорит .html или .php. И поскольку разработчик, использующий эти расширения, на самом деле не имеет смысла. Вы хотите, чтобы ваше приложение имело смысл, и эти расширения на самом деле не дают понимания, которое нужно пользователю.
Временами, которые вы хотели бы использовать, были, если вы создавали службу, которую будут использовать другие приложения. Затем вы можете использовать расширение, чтобы обозначить, какие данные можно было бы ожидать (.json,.xml и т.д.). Есть люди, которые работают над проектами и спецификациями для этого материала, но все это раннее
В основном эти расширения используются потому, что по умолчанию работали веб-серверы/клиенты. По мере развития веб-разработки мы стали более профессионально обрабатывать URL-адреса и пытались сделать их понятными для людей, читающих/использующих их.
В то время как расширения не имеют значения для браузера, который просто использует заголовки, переданные вместе с ним, чтобы определить, что отображать и как отображать его, скорее всего, они делают на сервере. Например, в вашем ящике может быть установлен как php, так и ruby-интерпретатор, но ваш веб-сервер имеет файлы конфигурации для сопоставления расширений файлов с типами MIME. Например, из Apache php5.conf:
AddType application/x-httpd-php .php .phtml .php3
который сообщает Apache, что файлы, заканчивающиеся на .php,.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 файл как .avi. Так почему бы просто не оставить это? Это позволяет использовать более короткие 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. API REST не должен включать искусственные расширения файлов в URI, чтобы указать формат тела сущности сообщений. Вместо этого они должны полагаться на тип носителя, который передается через заголовок Content-Type, чтобы определить, как для обработки содержимого bodys.
(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 файлов механизм, заголовок запроса принятия. ссылки: дизайн 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
важно, чтобы код работал на моем сайте.
для этого не требуется расширение файла.
"www.youtube.com/watch" - это каталог YouTube. Поэтому его можно в принципе написать как "www.youtube.com/watch/" с окончанием косой черты.