Как бы вы создали hackable url

Question

Представьте, что у вас была группа категорий продуктов, организованная в красивой иерархии деревьев, и вы хотели бы предоставить взломанные 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 

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

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

Каковы ваши мысли на этом?

Answer 1

Глубокие пути irk me. Они отвратительны.

 
/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. 

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

Take php.net

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

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

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

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

Answer 2

Все они выглядят прекрасно (за исключением одного с толстой кишкой).

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

Answer 3

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

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

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

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

И так далее, чтобы привести его в соответствие.

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

Answer 4

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

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

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

Answer 5

мне нравится/видеоигры/ИмяКонсоли/жанр/название»и использовать количество/'s, чтобы различать категории или продукт. Единственным, что я бы беспокоился о нескольких (или трудно отличить) я настоятельно рекомендую не расширять название. Вы также можете сделать что-то вроде видеоигр (.php)? c = x360; t = забвение и просто угадать недостающую информацию, но мне нравится метод /, поскольку он выглядит более аккуратным. вы добавляете жанр? Может быть, проще использовать первую букву названия или просто сделать видеоигр/консоль/заголовок/

Answer 6

Позволяет отключить ваш URL, чтобы быть более сухим (не повторяющимся). Вот что вы начинаются с Ith:

/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 

Oh, и если oblivion не является уникальным продуктом, просто построить слизняка, который включает в себя это ID:

/1234-oblivion 

Answer 7

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

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

Answer 8

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

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

Лучше URLs дизайн пункт по идентификаторам (т.е./пункт/435 /)

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

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

Answer 9

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

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

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

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