Древовидность и урлы

Продолжим тему нормальных урлов. Некоторые ребята думают, что хороший урл получается, если бездумно заменить в адресе всю служебную хрень на прямые слеши. Эти идиотские урлы видны невооружённым глазом. Например, вместо site.ru/?article=4972304 делают site.ru/article/4972304/.

Такой «красивый» урл ничем не лучше исходного. Он даже хуже: он показывает нам древовидность там, где её нет. Кажется, будто текущая страница — дочерняя для страницы site.ru/article/, на которой 404 или вообще какая-нибудь ошибка ПХП отображается.

Вместо article должно быть написано articles, а по адресу site.ru/acticles/ должен быть список статей. А если он и так показывается на главной, то страница отдельной статьи должна быть дочерней по отношению к главной: site.ru/4972304/. Если уж очень хочется запихать слово article в адрес, то нужно писать: site.ru/article-4972304/.

Урлы с бессмысленным набором слов и чисел, разделённых слешами, являются следствием бездумной конвертации внутренней логики веб-приложения в формат, «похожий на урл». Есть какой-нибудь класс Article, или файл article.php, или функция article (), и в урл его название и попадает.

Конечно, структура сайта чаще всего не является строго древовидной. Частое отклонение — главная страница сайта одновременно и корневая, и соседняя для страниц второго уровня. Но беды в этом никакой нет: на уровне урла всё равно всегда можно решить, к какому из двух уровней относить страницу. В большинстве случаев решение стоит принимать в пользу более короткого урла, потому, что иначе появится ненастоящий промежуточный уровень иерархии. В тех же редких случаях, когда промежуточный уровень появляется, он должен просто тихо редиректить на «настоящую» страницу.

Подписаться на блог
Поделиться
Отправить
Дальше
22 комментария
Алексей Кириченко 2009

Однозначно! Очень задолбало из [site.ru/article/4972304/] удалять 4972304/ и получать 404... :o((

Павел Урусов 2009

Забавно, когда мы переводили свой сайт на «красивые» урлы, я подсознательно настроил всё именно таким образом. Мне говорили, что адрес должен быть вида [site.ru/категория/дата/название_заметки]. Но я сделал урл вида [site.ru/категория/дата_название_заметки] именно для того, чтобы избежать ошибки 404, когда пользователь стирает название_заметки с целью попасть на уровень выше.

Артём Курапов 2009

Не все пхпшники осилили правильную работу с деревьями. Меня вот тоже задолбали урлы вида /meanwhile/2009/05/25/2/
Как будто в датах есть какая-то семантика (кроме очевидных типа 911). Деревья должны быть категориями/рубриками. Если их нет — пишите в модуль новостей где важны даты.

Илья Бирман 2009

Урлы отражают реальную структуру данных на этой сайте. Они коротки и точны. В них нет лишней служебной информации. Они идеальны.

Однако, сама структура данных более чем сомнительна. Совершенно непонятно, зачем распихивать заметки по ячейкам с датами. Но ведь это совсем другая тема, правда? :-)

clops 2009

я вот всегда запариваюсь с адресами даже в админках, однако статистика посещений показывает, что _никто_ не корректирует адреса — почему? все больше и больше склоняюсь к тому, что для удачного seo достаточно в url иметь точную копию тега title

Эдуард Гомоляко 2009

Павел, по запросу site.ru/категория/дата/ можно выводить все заметки на указанную дату, причем если дата вида /год/месяц/день/, то удаляя по уровню, получить можно заметки за день, месяц и год. на ленте.ру вроде так.

Сергей М. 2009

Если что, и здесь так же.

андрей андреев 2009

руби он рэйлс рулят
;-)

Oleg Andreev 2009

Привет, Андрюха! :-)

А вообще, конечно, рулят урлы как на википедии. Все остальное — фенечки.

Сергей 2009

OMG.
Разве это всё не очевидно? Разве не об этом нам как бы говорит W3C?

Сергей 2009

А время тут в какой зоне? Извините, если не к месту, приятно было бы видеть время без указания зоны локальным для меня. А то я аж вздрогнул весь — думаю, неужели я засиделся и уже пол-третьего ночи?! А оно всего-то пол-двенадцатого.

Илья Бирман 2009

GMT+5.

Павел Урусов 2009

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

Андрей Руденко 2009

Я могу написать еще разок. Не поленитесь и наберите «REST» в гугле. Тогда вместо этой заметки будет стоять гораздо более полезный линк на википедию.

bes island 2009

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

Например, пусть у нас на сайте есть список людей. И он делится по профессиям.

А ещё его можно сузить по первой букве фамилии, причём как весь список, так и список людей какой-то профессии.

А ещё список длинный и делится на страницы, и номер страницы должен быть представлен в адресе.

/people?letter=k, /people?page=3, /people?job=teacher&letter=k&page=3 — здесь всё более-менее понятно.

Попытаемся сделать /people/teachers/ — возникает вопрос, как обозначать страницу, где все-все люди на букву «K». Или третью страницу общего списка людей.

Придётся, наверное, сделать /people/jobs/teachers и /people/pages/3, где /people/jobs может отображать список всех профессий, а /people/pages — тихо отправлять на /people.

В конечном итоге придём к адресам вида /people/jobs/teachers/letters/k/pages/3 — то есть именно к тому, о чём говорится в начале заметки. Служебная хрень заменена косыми чертами, только и всего.

Атясов Денис 2009

Как насчет site.ru/article/4972304.html?

Атясов Денис 2009
  • Конечно же имел ввиду site.ru/articleS/4972304.html?
Илья Бирман 2009

##.html## — мусор.

Андрей Руденко 2009

Тем не менее сайт должен понимать указание не только .html, но и .xml, .rss, .json, если это не закрытый раздел, конечно.

В общем то делать надо так как давным давно сделано в рельсах.

Oleg Andreev 2009

К #13: напротив, очень легко. Нужно почитать RFC 1630:

QUERY STRINGS

The question mark («?», ASCII 3F hex) is used to delimit the
boundary between the URI of a queryable object, and a set of words
used to express a query on that object. When this form is used,
the combined URI stands for the object which results from the
query being applied to the original object.

Т. е. «/путь/через/слеши» определяет путь к ресурсу, а «?строка=запроса» — собственно, запрос к этому ресурсу. Если вы делаете сложный поиск по людям, то правильный, простой и понятный адрес выглядит так: /people?name_start=K&category=X

Здесь человек сразу видит, что если убрать всю строку запроса, то выдадут всех людей подряд, а если убрать лишь один из параметров — будет убран соответствующий критерий. Хотя, опять-таки, никто руками в адресную строку, как правило, не лезет.

Oleg Andreev 2009

#16: сайт не обязан понимать какие-то xml, rss или html.
Он должен выдавать понятный ответ на естественный запрос. Если у вас есть ресурс /people в html и xml форматах, то да, сайт должен отвечать не на /people_html и /people/format?type=xml, а на /people.html и /people.xml. А если на /people.rss выдается 406 Not Acceptable, то нет такого формата и сайт никому ничего не должен.

Андрей Руденко 2009

#18 Но ведь было бы классно :)

Oleg Andreev 2009

#19: еще было бы классно иметь /people/123.vrml с трехмерной моделью персонажа. И чтобы оно «само» в рубионрельсах генерировалось, да.

Эдуард Гомоляко 2009

Кстати, поскольку мы тут разговариваем про URL’ы, которые запрашиваются по протоколу HTTP, то насчет .xml, .rss, .html, могу сказать, что можно использовать header accept, в котором указать в каком виде нужно получить по адресу /articles/2553/

с другой стороны в данном случае через браузер будет трудно получить тот или иной ресурс в формате, отличным от HTML.

поскольку я реализую доступ к такого вида ресурсам через контроллеры, то предпочитаю делать обработку урлов вида /artciles/2553/.xml или /articles/2553/.html, где внутри слешей адрес ресурса, а с точкой идет имя метода, сериализующего объект ресурса.

Илья Бирман 2009

А видеть приятнее будет /articles/2553/ и /articles/rss/, безотносительно сериализации объекта ресурса (кстати, последние три слова можно поставить в любом порядке, и никто не заметит разницы :-)

Сергей К. 2009

Я для себя выбрал вариант /yyyy/mm/dd/useful-title. Тогда, глядя на адрес (например, в статистике), можно сразу вспомнить, о чём эта статья. Useful-title, естественно, пишется вручную по смыслу. По дням я не вспомню никогда даже на своём сайте. Поэтому адрес вида «второй пост за 25 мая 2009 года» тоже не идеален.

Мои книги