Проектирование адресного пространства сайта

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

Ниже описан пример проектирования системы адресации на примитивном уровне. Впрочем, я уверен, многим сайтам даже такое планирование поможет стать лучше.

Постановка задачи
Скажем, мы делаем коллективный блог. В него пишут несколько авторов-экспертов. Есть главная лента со всеми свежими записями. И есть множество лент, которые «режут» контент по годам, по авторам, по тегам. Кстати, история основана на реальных событиях.

Базовое решение
site.ru/ — главная страница сайта.
site.ru/blog/ — блог.
site.ru/blog/2004/ — записи в блоге за 2004 год.

site.ru/blog/2004/
if-it-can-be-fixed.html — постоянный адрес записи, permalink.

site.ru/blog/2004/
it-can-be-fixed-12-june.html — снизим шансы появления в течение года еще одной записи с таким же названием, добавив в импровизированное имя файла дату.

Проблема нескольких плоскостей
Теперь придумаем структуру адреса отдельных авторских лент. Одного из наших блоггеров зовут Athabaska Dick (привет Reno Jimmy). Итак, какой же у ленты адрес?

site.ru/blog/authors/athabaska-dick/ — может так? Нет, плохо. Обычно так выглядят адреса страниц с информацией об авторе.

site.ru/blog/athabaska-dick/ — вроде хорошо.
site.ru/blog/athabaska-dick/
it-can-be-broke-12-june.html — резонно постоянный адрес записи сделать таким.

Вот и небольшая проблема: у нас уже есть постоянный адрес, содержащий год. Сделать две разных ссылки на одну запись? Это не понравится ни посетителям, ни поисковикам, да и владельцу сайта ни к чему.

site.ru/blog/2004/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/
it-can-be-fixed-12-june.html

Проблема фильтрации по нескольким критериям
Наш коллективный блог планируется достаточно масштабным, так что понадобится фильтрация не только по годам и по авторам, но и по годам и авторам.

Вот и четыре наших альтернативы.

site.ru/blog/2004/
it-can-be-fixed-12-june.html
site.ru/blog/2004/athabaska-dick/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/2004/
it-can-be-fixed-12-june.html

Если критериев будет больше, программист сойдет с ума.

Решение для простых случаев
site.ru/blog/
it-can-be-fixed-12-june-2004.html — в постоянных ссылках на самом деле не существует никаких каталогов. Уберем их из адресов страниц. И добавим в дату год.

Если нужна фильтрация максимум по одному критерию, сделаем так.

site.ru/blog/athabaska-dick/
site.ru/blog/2004/
site.ru/blog/PHP+MySQL/

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

site.ru/blog/by-author/athabaska-dick/
site.ru/blog/years/2004/
site.ru/blog/tags/PHP+MySQL/

Решение для крупных систем
site.ru/blog/?author=athabaska-dick&
year=2004&category1=PHP&category2=MySQL — классический вариант с километром переменных. Супернедружественный и супергибкий.

site.ru/blog/author:athabaska-dick+
year:2004+categories:PHP,MySQL/ — можем уделить этому внимание и сделать очень внушительно. Оправдано ли?

Постраничный вывод
Постраничный вывод лент делаем в самом конце, либо с переменными, либо с дополнительным фальшивым каталогом.

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