Когда я смотрю на Amazon.com и вижу их URL-адреса страниц, в конце URL-адреса нет .htm, .html или .php.
Это примерно так:
http://www.amazon.com/books-used-books-textbooks/b/ref=topnav_storetab_b?ie=UTF8&node=283155
Почему и как? Что это за расширение?
Ваш браузер не заботится о расширении файла, а только о типе содержимого, о котором сообщает сервер. (Ну, если вы не используете IE, потому что в Microsoft думают, что они знают больше о том, что вы предлагаете, чем вы). Если ваш сервер сообщает, что обслуживаемый контент имеет тип Content-Type: text/html, то ваш браузер должен обрабатывать его как HTML, независимо от имени файла.
Как правило, это реализуется с помощью схемы перезаписи URL-адреса некоторого описания. Основная идея заключается в том, что Интернет должен переходить к адресации ресурсов с помощью правильных URI, а не классических старых URL-адресов, из-за которых происходит утечка деталей реализации и которые в результате уязвимы для будущих изменений.
Подробное обсуждение этой темы можно найти в статье Тима Бернерса-Ли Крутые URI не меняются, который выступает в пользу уменьшения ненужного мусора в URI как средства, помогающего избежать проблем, возникающих при изменении реализации и при перемещении ресурсов на другой URL-адрес. Сама статья содержит хорошие общие советы по планированию схемы URI, и ее стоит прочитать.
Более конкретно, чем большинство этих ответов:
Веб-контент не использует расширение файла, чтобы определить, какой файл обслуживается (если вы не используете Internet Explorer). Вместо этого они используют HTTP-заголовок Content-type, который отправляется по сети перед содержимым изображения, HTML-страницы, загрузки или чего-то еще. Например:
Content-type: text/html
означает, что просматриваемая вами страница должна интерпретироваться как HTML, и
Content-type: image/png
означает, что страница представляет собой изображение PNG.
Веб-серверы часто используют расширение файла, если файл обслуживается непосредственно с диска, чтобы определить, какое Content-type назначать, но веб-приложения также могут генерировать страницы с любым Content-type, которое им нравится, в ответ на запрос. Независимо от структуры или расширения имени файла, если фактическое содержимое страницы совпадает с заявленным Content-type, данные отображаются так, как предполагалось.
Для веб-сайтов, использующих Apache, они, вероятно, используют mod_rewrite, который позволяет им переписывать URL-адреса (и делает их более удобными для пользователя и SEO)
Вы можете прочитать больше здесь http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html и здесь http://www.sitepoint.com/article/apache-mod_rewrite-examples/
EDIT: для IIS также есть модули перезаписи.
Традиционно расширение файла представляет файл, который обслуживается.
Например
Позже тот же подход был использован для того, чтобы сценарий мог обрабатывать параметр
http://somerverser/somepath/script.php?param=1234&other=7890
В этом случае файл представлял собой php-скрипт, который обрабатывал «запрос» и представлял динамически созданный файл.
В настоящее время приложения намного сложнее (а именно Amazon, о котором вы говорили)
Тогда нет единого сценария, который обрабатывает запрос (но гораздо более сложное приложение с несколькими файлами/методами/функциями/объектом и т. д.), а URL-адрес больше похож на точку входа для веб-приложения (за ним может быть сценарий но это другое), так что теперь веб-приложения, такие как amazon и да, stackoverflow не отображают файл в URL-адресе, но все, что приходит, обрабатывается приложением на стороне сервера.
Здесь I questions представляет веб-приложение, а 322747 параметр
Я надеюсь, что это небольшое объяснение поможет вам лучше понять все остальные ответы.
Как насчет того, чтобы иметь файл index.html в каталоге, а затем ввести путь в браузере? Я вижу, что мой Firefox и IE7 автоматически вставляют косую черту в конце, мне не нужно ее вводить. Это больше подходит для таких людей, как я, которые не думают, что каждый отдельный URL-адрес на земле должен вызывать php, perl, cgi и 10 000 других приложений только для того, чтобы отправить несколько килобайт данных.
Многие люди используют архитектуру типа "RESTful"... или, по крайней мере, REST-выглядящие URL-адреса.
На этом сайте (StackOverflow) не отображается расширение файла... он использует ASP.NET MVC.
В зависимости от настроек вашего сервера вы можете использовать (или не использовать) любое расширение. Вы даже можете установить расширения «.JamesRocks», но это не очень поможет :)
В любом случае, на случай, если вы новичок в веб-программировании, вся эта тарабарщина в конце содержит аргументы для операции GET, а не расширения страницы.
Об этом упоминалось в ряде постов, и я буду взвешивать. Это абсолютно система перезаписи URL-адресов, и на ряде платформ есть способы реализовать это.
Я работал на нескольких крупных сайтах электронной коммерции, и теперь это очень важная часть присутствия в Интернете, предлагающая ряд преимуществ.
Я бы рекомендовал взять технологию, с которой вы хотите работать, и изучить образцы механизма перезаписи URL для этой платформы. Для .NET, например, гуглите «переписывание URL-адресов asp.net» или используйте дополнительную структуру, такую как MVC, которая делает эту функциональность из коробки.
В Django (инфраструктура веб-приложений для python) вы сами создаете URL-адреса, независимо от имени файла или даже пути на сервере, если на то пошло.
Вы просто говорите что-то вроде «Я хочу, чтобы эта функция обрабатывала /news/<number>/ URL».
