Каковы плюсы использования URL-адресов без расширений?

Причина URL-адресов без расширения заключается в том, что они не зависят от технологии. Если вы хотите изменить способ отображения вашего контента, вам не нужно менять URL-адрес.

W3: классные URI не меняются

Расширение имени файла

This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension....

Вывод

Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

В основном это делается в эстетических целях.

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

Соответствующая запись в блоге.

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

Если вы используете IIS 7, вы можете переключить пул приложений для работы в интегрированном конвейере, тем самым устраняя необходимость в сопоставлении определенных расширений с механизмом ASP.NET. Как только это будет сделано, вы можете указать Sitecore использовать URL-адреса без расширений в настройках web.config (при условии, что Sitecore 6):

<linkManager defaultProvider="sitecore">
  <providers>
    <clear />
    <add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel" 
         addAspxExtension="false"    /* This one is set to true, per default */
         alwaysIncludeServerUrl="false" 
         encodeNames="true" 
         languageEmbedding="asNeeded" 
         languageLocation="filePath" 
         shortenUrls="true" 
         useDisplayName="false" />
  </providers>
</linkManager>

Готово.

Имейте в виду, что в ранних версиях Sitecore 6 было несколько проблем при запуске Integrated Pipeline. Дополнительную информацию можно найти здесь.

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

Но это актуально только в рамках «маршрутизируемого» кода, где вы в основном привязываете маршруты URL к коду.

Например, в моей библиотеке кода вы можете указать разрешенный выходной формат URL-адреса с помощью

1) Установка заголовка Accept в заголовке HTTP 2) Прикрепление действительного расширения к URL-адресу

Таким образом, код для /my/simple/url.html, /my/simple/url.xml и /my/simple/url.json абсолютно одинаков. Менеджер вывода будет нести ответственность за вывод контента надлежащим образом.

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

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

Потому что пользователю не нужно знать технологию, стоящую за страницей. Пример: domain.com/Programs/Notepad

Единственное, о чем я могу думать, это облегчить конечному пользователю запоминание/печать, кроме того, что я не вижу никакой причины, я также запустил это нашим администратором, и он говорит, что некоторые говорят, что SEO, но если он будет использовать это, он использовал бы это для уровня, если безопасность.