Древовидность и урлы
Продолжим тему нормальных урлов. Некоторые ребята думают, что хороший урл получается, если бездумно заменить в адресе всю служебную хрень на прямые слеши. Эти идиотские урлы видны невооружённым глазом. Например, вместо 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 (), и в урл его название и попадает.
Конечно, структура сайта чаще всего не является строго древовидной. Частое отклонение — главная страница сайта одновременно и корневая, и соседняя для страниц второго уровня. Но беды в этом никакой нет: на уровне урла всё равно всегда можно решить, к какому из двух уровней относить страницу. В большинстве случаев решение стоит принимать в пользу более короткого урла, потому, что иначе появится ненастоящий промежуточный уровень иерархии. В тех же редких случаях, когда промежуточный уровень появляется, он должен просто тихо редиректить на «настоящую» страницу.
Однозначно! Очень задолбало из [site.ru/article/4972304/] удалять 4972304/ и получать 404... :o((
Забавно, когда мы переводили свой сайт на «красивые» урлы, я подсознательно настроил всё именно таким образом. Мне говорили, что адрес должен быть вида [site.ru/категория/дата/название_заметки]. Но я сделал урл вида [site.ru/категория/дата_название_заметки] именно для того, чтобы избежать ошибки 404, когда пользователь стирает название_заметки с целью попасть на уровень выше.
Не все пхпшники осилили правильную работу с деревьями. Меня вот тоже задолбали урлы вида /meanwhile/2009/05/25/2/
Как будто в датах есть какая-то семантика (кроме очевидных типа 911). Деревья должны быть категориями/рубриками. Если их нет — пишите в модуль новостей где важны даты.
Урлы отражают реальную структуру данных на этой сайте. Они коротки и точны. В них нет лишней служебной информации. Они идеальны.
Однако, сама структура данных более чем сомнительна. Совершенно непонятно, зачем распихивать заметки по ячейкам с датами. Но ведь это совсем другая тема, правда? :-)
я вот всегда запариваюсь с адресами даже в админках, однако статистика посещений показывает, что _никто_ не корректирует адреса — почему? все больше и больше склоняюсь к тому, что для удачного seo достаточно в url иметь точную копию тега title
Павел, по запросу site.ru/категория/дата/ можно выводить все заметки на указанную дату, причем если дата вида /год/месяц/день/, то удаляя по уровню, получить можно заметки за день, месяц и год. на ленте.ру вроде так.
Если что, и здесь так же.
руби он рэйлс рулят
;-)
Привет, Андрюха! :-)
А вообще, конечно, рулят урлы как на википедии. Все остальное — фенечки.
OMG.
Разве это всё не очевидно? Разве не об этом нам как бы говорит W3C?
А время тут в какой зоне? Извините, если не к месту, приятно было бы видеть время без указания зоны локальным для меня. А то я аж вздрогнул весь — думаю, неужели я засиделся и уже пол-третьего ночи?! А оно всего-то пол-двенадцатого.
GMT+5.
Эдуард, дело в том, что уже через день после публикации заметки её дата становится нерелевантной. Я в этом совершенно убеждён, не надо даже спорить. :) Поэтому и не стал тратить время/силы на реализацию такого механизма.
Я могу написать еще разок. Не поленитесь и наберите «REST» в гугле. Тогда вместо этой заметки будет стоять гораздо более полезный линк на википедию.
Не возражая против вышенаписанного, замечу, что для сколько-нибудь сложных случаев придумать систему понятных адресов очень нелегко.
Например, пусть у нас на сайте есть список людей. И он делится по профессиям.
А ещё его можно сузить по первой букве фамилии, причём как весь список, так и список людей какой-то профессии.
А ещё список длинный и делится на страницы, и номер страницы должен быть представлен в адресе.
/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 — то есть именно к тому, о чём говорится в начале заметки. Служебная хрень заменена косыми чертами, только и всего.
Как насчет site.ru/article/4972304.html?
##.html## — мусор.
Тем не менее сайт должен понимать указание не только .html, но и .xml, .rss, .json, если это не закрытый раздел, конечно.
В общем то делать надо так как давным давно сделано в рельсах.
К #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
Здесь человек сразу видит, что если убрать всю строку запроса, то выдадут всех людей подряд, а если убрать лишь один из параметров — будет убран соответствующий критерий. Хотя, опять-таки, никто руками в адресную строку, как правило, не лезет.
#16: сайт не обязан понимать какие-то xml, rss или html.
Он должен выдавать понятный ответ на естественный запрос. Если у вас есть ресурс /people в html и xml форматах, то да, сайт должен отвечать не на /people_html и /people/format?type=xml, а на /people.html и /people.xml. А если на /people.rss выдается 406 Not Acceptable, то нет такого формата и сайт никому ничего не должен.
#18 Но ведь было бы классно :)
#19: еще было бы классно иметь /people/123.vrml с трехмерной моделью персонажа. И чтобы оно «само» в рубионрельсах генерировалось, да.
Кстати, поскольку мы тут разговариваем про URL’ы, которые запрашиваются по протоколу HTTP, то насчет .xml, .rss, .html, могу сказать, что можно использовать header accept, в котором указать в каком виде нужно получить по адресу /articles/2553/
с другой стороны в данном случае через браузер будет трудно получить тот или иной ресурс в формате, отличным от HTML.
поскольку я реализую доступ к такого вида ресурсам через контроллеры, то предпочитаю делать обработку урлов вида /artciles/2553/.xml или /articles/2553/.html, где внутри слешей адрес ресурса, а с точкой идет имя метода, сериализующего объект ресурса.
А видеть приятнее будет /articles/2553/ и /articles/rss/, безотносительно сериализации объекта ресурса (кстати, последние три слова можно поставить в любом порядке, и никто не заметит разницы :-)
Я для себя выбрал вариант /yyyy/mm/dd/useful-title. Тогда, глядя на адрес (например, в статистике), можно сразу вспомнить, о чём эта статья. Useful-title, естественно, пишется вручную по смыслу. По дням я не вспомню никогда даже на своём сайте. Поэтому адрес вида «второй пост за 25 мая 2009 года» тоже не идеален.