Как бы вы разработали взломанный URL - PullRequest
2 голосов
/ 14 ноября 2008

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

/catalog/categorya/categoryb/categoryc

Тогда вы могли бы довольно легко определить, для какой категории вы должны перечислить товары (обратите внимание, что необходим полный URL-адрес, поскольку у вас могут быть категории с тем же именем, но в разных местах в иерархии)

Теперь, что было бы хорошим подходом для добавления информации о продукте? В качестве примера вы хотели бы отобразить продукт Oblivion для этой категории

/catalog/games/consoles/playstation/adventure

Заманчиво просто добавить товар в конце URL

/catalog/games/consoles/playstation/adventure/oblivion

но в тот момент, когда вы это делаете, вы теряете способность знать, относится ли его категория или продукт, который называется забвением. Я лично чувствую, что меня не заставляют добавлять суффикс, такой как .html

/catalog/games/consoles/playstation/adventure/oblivion.html

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

/catalog/games/consoles/playstation/adventure/product:oblivion

Вы также можете добавить какой-нибудь триггер, например

/catalog/games/consoles/playstation/adventure/PRODUCT/oblivion

тоже не так хорошо, и вы (хотя и маловероятно, что это будет проблемой) ограничат себя от категории product

До сих пор суффиксное решение выглядело как наиболее удобный для пользователя подход, о котором я только могу подумать, но мне не нравится использовать расширение

Что вы думаете об этом?

Ответы [ 9 ]

10 голосов
/ 22 ноября 2008

Глубокие пути раздражают меня. Они отвратительны, чтобы поделиться.

<sub>
/product/1234/oblivion --> direct page
/product/oblivion --> /product/1234/oblivion if oblivion is a unique product, 
                  --> ~ Diambiguation page if oblivion is not a unqiue product. 

/product/1234/notoblivion -> /product/1234/oblivion

/categories/79/adventure -->  playstation adventure games
/categories/75/games -->  console games page
/categories/76/games -->  playstation games page 
/categories/games --> Disambiguation Page. 
</sub>

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

Возьми php.net

php.net/str_replace -->  goes to 
  http://nz2.php.net/manual/en/function.str-replace.php

И эта модель настолько взломана, что люди все время используют ее вслепую.

Примечание. W3C считает суффикс .html функционально бессмысленным и избыточным, и его следует избегать в URL-адресах.

http://www.w3.org/Provider/Style/URI

6 голосов
/ 22 ноября 2008

Позволяет отсеять ваш URL, чтобы быть более СУХОЙ (неповторяющейся). Вот с чего вы начинаете:

/catalog/games/consoles/playstation/adventure/oblivion

Действительно, категория adventure является избыточной, поскольку игра может принадлежать нескольким жанрам.

/catalog/games/consoles/playstation/oblivion

Следующее, что меня поражает, это то, что консоли тоже не нужны. Вероятно, не стоит проводить различие между ПК и консольными машинами как подразделом. Это все типы машин, и, делая это, вы просто добавляете еще один уровень сложности.

/catalog/games/playstation/oblivion

Теперь вы находитесь на этапе принятия некоторых решений относительно вашего сайта. Я бы порекомендовал удалить категорию playstation на своей странице, поскольку игра может существовать на нескольких платформах, а также в категории games. Ваш URL должен выглядеть так:

/catalog/oblivion

Итак, как получить список всех экшн-игр для Playstation?

/catalog/tags/playstation+adventure

или, возможно,

/catalog/tags/adventure/playstation

Порядок не имеет значения. Вы также должны убедиться, что tags является зарезервированным именем для продукта.

Наконец, я предполагаю, что вы не можете удалить корень /catalog из-за конфликтов. Однако, если ваш сайт крошечный и не имеет много других разделов, тогда сведите все к корневому уровню:

/oblivion
/tags/playstation/adventure

Да, и если oblivion не является уникальным продуктом, просто создайте слаг, включающий его идентификатор:

/1234-oblivion
1 голос
/ 23 ноября 2008

Одна проблема заключается в том, что представление вашего пользователя о «группе категорий товаров, организованных в виде красивой древовидной иерархии», может совпадать с вашим. Вот технический доклад Google Дэвида Вайнбергера «Все по-другому» с некоторыми интересными идеями по категоризации материала:

http://www.youtube.com/watch?v=x3wOhXsjPYM

1 голос
/ 14 ноября 2008

Если вы видите разные части в качестве целей, то сам продукт - просто еще одна цель Все цели должны быть доступны по target.html или только по цели.

Каталог / Игры / Консоли / playstation.html
Каталог / Игры / приставки / PlayStation

Каталог / Игры / приставки / PlayStation / adventure.html
Каталог / Игры / Консоли / PlayStation / приключения

Каталог / Игры / приставки / PlayStation / приключения / oblivion.html
Каталог / Игры / приставки / PlayStation / приключения / забвение

И так далее, чтобы сделать его последовательным.

Мои 5 центов ...

1 голос
/ 14 ноября 2008

Все они выглядят хорошо (кроме одного с двоеточием).

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

0 голосов
/ 23 ноября 2008

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

И что? Нет реальной необходимости проводить четкое различие между продуктами и категориями, в первую очередь в URI, за исключением, возможно, проблемы с производительностью при дополнительном обращении к базе данных. Если это действительно так важно для вас, рассмотрите следующие два предложения:

  1. Большинство просмотров страниц, скорее всего, будут относиться к товарам, а не к категориям. Таким образом, выполнение проверки продукта в первую очередь минимизирует частоту, с которой вам нужно удваивать количество запросов к базе данных.
  2. Добавьте код в свое приложение, чтобы отобразить время, затрачиваемое на создание каждой страницы, а затем выйдите в ближайшее интернет-кафе ( не во внутренней локальной сети! ) с секундомером. Поднимите несколько страниц с вашего сайта и укажите, сколько времени уходит на их создание. Вычтите время, необходимое для создания страницы. Также сравните время, затрачиваемое на создание страниц с поиском по одной базе данных и со страницами поиска по двум базам данных. Затем спросите себя, когда для установления сетевого соединения, генерации и загрузки контента может потребоваться всего 1-2 секунды, действительно ли имеет значение, тратите ли вы лишние 0,05 секунды или меньше на дополнительный поиск в базе данных или нет?

Оптимизируйте, где это важно, например, создавая URL-адреса, которые будут удобны для человека (как в ответе Криса Ллойда). Не тратьте свое время, пытаясь сбрить последнюю возможную долю процента.

0 голосов
/ 23 ноября 2008

Мой скромный опыт, хотя и не связанный с продажей игр, говорит мне:

  • редакторы часто не используют лучшие имена для этих "слизней", они не выбирают их мудро.
  • многие элементы принадлежат (логически) к нескольким категориям, так зачем ограничивать их (технически) одной категорией?

URL-адреса лучшего дизайна по идентификаторам, (т.е. / item / 435 /)

  • идентификаторы стабильны (генерируются БД, не редактируются редактором), поэтому у URL гораздо больше шансов не измениться со временем
  • они не раскрывают (или не зависят) организацию объектов в базе данных, как это делает стиль url категории / item_name. Что если вы измените базовый дизайн (структуру объекта), чтобы элемент мог принадлежать нескольким категориям? URL категории / элемента внезапно перестанут иметь смысл; Вы измените свой дизайн URL-адреса, и старые URL-адреса могут больше не работать.

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

0 голосов
/ 22 ноября 2008

Мне нравится / videogames / consolename / genre / title ", и я использую количество символов / s, чтобы различать категорию или продукт. Единственное, что меня беспокоит из-за мульти (или трудно различимого) жанра. Я настоятельно рекомендую нет расширение на заголовок. Вы также можете сделать что-то вроде видеоигры (.php)? c = x360; t = забвение, и просто угадать недостающую информацию, однако мне нравится метод /, так как он выглядит более аккуратно. Почему вы добавляете жанр? Проще использовать первую букву заголовка или просто сделать видеоигру / console / title /

0 голосов
/ 14 ноября 2008

@ Лу Франко: да, любой метод нуждается в надежном резервном механизме, и отправка его на какую-то страницу предложений или механизм поиска может быть хорошим кандидатом

@ Стефан, проблема в том, чтобы рассматривать их как цели, состоит в том, как их различить (как я описал). В худшем случае вы сначала попадаете в свою базу данных, чтобы увидеть, существует ли категория, которая удовлетворяет пути, и если нет, тогда вы проверяете, есть ли продукт, который делает. Проблема в том, что для каждого пути продукта вы в конечном итоге будете делать бесполезный вызов в базу данных, чтобы убедиться, что это не категория.

@ некоторые да, разделитель может быть возможным решением, но тогда суффикс .html является более удобным и общеизвестным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...