Что предотвращает исправление проблемы «Вставьте все, что вы хотите в URL», которая есть в некоторых системах управления контентом?

Question

Я не понимаю, какие реальные проблемы мешают системе запрещать подобные URL-адреса?

http://www.washingtonpost.com/hey-this-url-doesn't-mean-a-damn-thing/gIQAocHrpJ_story.html

Я понимаю, что происходит. Система маршрутизации ищет ключ после окончательного обратного слеша. И затем он разбирает то, что после подчеркивания, чтобы построить версию.

Итак: washingtonpost.com/whwhat/gIQAocHrpJ_story.html приносит нам нормальную версию истории washingtonpost.com/whwhat/gIQAocHrpJ_print.html приносит нам обычную версию для печати washingtonpost.com/whwhat/gIQAocHrpJ_mobile.html приносит нам мобильную версию XML

Странно, даже изменение этого .html на другое распространенное расширение, такое как .js или .xml или вообще ничего, возвращает вас на ту же страницу. Однако, изменив его на что-то нестандартное, например .fffuuu, вы получите удобную для человека страницу 404 или полную пустую страницу. Это похоже на то, как программист CMS внес в белый список первые несколько типов файлов, которые пришли на ум и заставили систему обрабатывать их все одинаково.

Я только создавал простые сайты в Rails и Wordpress, так что я понимаю простые понятия о шаблонах URL, например, как константы префикса могут влиять на скорость поиска ... но я ошибаюсь, полагая, что здесь нет смысла или причины к приведенному выше шаблону проектирования?

Имейте в виду, «Вашингтон пост» совсем недавно завершила масштабный редизайн. Речь идет не о попытке обойтись с унаследованной системой, их дизайнеры CMS, по-видимому, имели свободу перенимать современные лучшие практики. Я просто не вижу преимуществ принятого ими шаблона проектирования url, за исключением того, что разработчик CMS не знает ничего лучше.

Как их текущая система работает быстрее, чем модель базы данных, которая имеет уникальный ключ, а затем удобочитаемое поле?

http://www.washingtonpost.com/HUMAN-READABLE-KEY/UNIQUE_KEY.html

Шаблон между обратной косой чертой домена и последней обратной косой чертой является читаемым человеком ключом. Система находит запись с помощью UNIQUE_KEY и затем проверяет, соответствует ли читаемый человеком ключ тому, что имеет БД для этой записи.

Я заметил, что в официальной версии ссылок, поскольку они генерируются с домашней страницы, есть информация о году / месяце / дне. Опять же, это бессмысленно, так как вы можете изменить их и получить ту же страницу (к счастью, ни один JS, похоже, не зависит от их разбора).

Я предполагаю, что разработчик CMS не хотел связываться с датами, так как новость может оборваться 20.08.2011, но версия для печати будет запущена 21.08.2011 ... Конечно, тогда просто не имеют даты вообще в URL. Если URL-адрес можно изменить на что-нибудь , не обучайте пользователя ожидать от него информации, специфичной для документа.

Даже первый термин после домена ничего не значит. Поэтому:

http://www.washingtonpost.com/politics/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html

Переходит к той же истории, что и

http://www.washingtonpost.com/sex/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html

И, наконец, разве это не портит Google и другие поисковые системы?

Answer 1

Основная причина, по которой это делается, заключается в том, чтобы убедиться, что, если заголовок изменится, читатели все равно смогут добраться до истории. «Слаг» (то, что вы называете читабельным человеком ключом: mitt-romney-debates-us-economy) обычно генерируется автоматически из заголовка страницы или текста заголовка. В некоторых старых CMS, где это не было хорошо продумано, изменение заголовка часто оставляло URL-адрес одинаковым (со старым слагом в нем). Как вы можете себе представить, иногда, когда первоначальный заголовок выбирался неправильно, это могло быть довольно неловко.

В результате большинство разработчиков CMS переключились на поиск истории на основе идентификатора, который намного легче убедиться, что он не изменится. Но что тогда делать со слизней? Некоторые CMS просто игнорируют это; это подход «Вашингтон пост».

Другое (довольно простое и, вероятно, лучшее) решение: Когда вы найдете свою историю в базе данных, убедитесь, что фрагмент URL-адреса соответствует фрагменту текущего в базе данных (на основе текущего заголовка). Если это не так, перенаправьте пользователя на правильный URL-адрес. С точки зрения конечного пользователя, это легко: вы набираете http://www.washingtonpost.com/hey-this-url-doesn't-mean-a-damn-thing/gIQAocHrpJ_story.html, а когда страница загружается, вы набираете http://www.washingtonpost.com/politics/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html

Почему Washington Post этого не делает, я не уверен; у них там много умных людей, поэтому, вероятно, есть какая-то отличная техническая причина, связанная с их конкретной CMS (которая, я думаю, основана на том, что они купили у продавца). В других системах описанное мной решение может быть выполнено очень легко (в Django я сделал это в три строки).