你会如何设计一个破解的URL

Question

想象一下，你有一组在一个不错的树状分层结构组织的产品类别，你想提供破解的URL来浏览这些。你可以做这样的事情

/catalog/categorya/categoryb/categoryc 

然后，你可以很容易地找出哪些类别你应该列出产品（注意，需要完整的URL，因为你可以有相同名称的类别，但在不同的位置层次结构）

现在是什么将是在添加产品信息以及一个好方法？给你举个例子，你想显示产品湮灭这一类别

/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

深深的路径让我感到厌烦。他们很难分享。

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

否则，长的URL，而似乎破解的，需要你把所有节点元素有权破解它。

采取php.net

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

而这一模式是如此容易被破解的人盲目地使用它所有的时间。

注意：.html后缀被W3C视为功能无意义和冗余，应避免在URL中使用.html后缀。

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

Answer 2

这些都看起来很好（除了冒号之一）。

最关键的是，当他们猜错了怎么办 - 不要把他们送到一个404 - 相反，把你不知道，并将它们发送到您的搜索页面结果这个词的话 - 甚至如果你能在那里拼写检查更好。

Answer 3

如果你看到不同的部分作为目标，则产品本身只是一个目标。 所有目标都应该可以通过target.html访问，或者只能访问目标。

目录/游戏/游戏机/ playstation.html
目录/游戏/游戏机/游戏机

目录/游戏/游戏机/游戏机/ adventure.html
目录/游戏/游戏机/游戏机/冒险

目录/游戏/游戏机/游戏机/冒险/ oblivion.html
目录/游戏/游戏机/游戏机/冒险/遗忘

等等，使其保持一致。

我5毛钱......

Answer 4

@Lou佛朗哥耶两种方法需要一个坚固的回退机制，并把它发送到某种暗示页面或SEACH发动机的将是很好的候选人

@Stefan的问题将两者都视为目标是如何区分它们（就像我所描述的那样）。在最坏的情况下，你首先打你的数据库，看看是否有一个满足路径的类别，如果没有，那么你检查是否有一个产品。问题在于，对于每条产品路径，最终都会对数据库进行无用的调用，以确保其不属于某个类别。

@some是一个分隔符可能是一个可能的解决方案，但后来一个.html后缀是更友好和通用的。

Answer 5

我喜欢/视频游戏/ consolename /流派/标题”，并使用/人的量类别或产品区别开来。我唯一会担心多（或很难区分）我强烈建议你不要在title上做任何扩展，你也可以做一些类似于视频游戏（.php）的东西？c = x360; t =遗忘;只是猜测缺少的信息，但是我喜欢/方法，因为它看起来更整齐。你添加的流派？它可能会更容易使用标题的第一个字母，或者只是做视频游戏/控制台/标题/

Answer 6

让我们检查您的网址，以便更干（非重复）。正在开始w第i：

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

真的，类别adventure是多余的，因为游戏可以属于多个流派。

/catalog/games/consoles/playstation/oblivion 

接下来让我想到的是控制台也不是必需的。将PC和控制台机器区分开来可能不是一个好主意。他们是所有类型的机器，通过这样做，你只是增加了另一层级的复杂性。

/catalog/games/playstation/oblivion 

现在您正在对您的网站做出一些决定。我建议您删除页面上的playstation类别，因为游戏可以跨多个平台存在，也可以存在games类别。你的网址应该是这样的：

/catalog/oblivion 

那么你如何获得Playstation所有动作游戏的列表？

/catalog/tags/playstation+adventure 

或许

/catalog/tags/adventure/playstation 

的顺序并不重要。您还必须确保tags是产品的保留名称。

最后，我假设您不能删除由于冲突导致的根/catalog。但是，如果你的网站是微小的，没有多少其他部分则都减少到根级：

/oblivion 
/tags/playstation/adventure 

哦，如果oblivion不是独一无二的产品只是构建一个蛞蝓，其中包括它的ID：

/1234-oblivion 

Answer 7

一个问题是，您的用户对“在一个漂亮的树层次结构中组织的产品类别组”的概念可能与您匹配。 这里是由大卫·温伯格的一个谷歌的技术对话“一切都是杂”与分类的东西一些有趣的想法：

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

Answer 8

我卑微的经历，虽然没有涉及到畅销的游戏，告诉我：

• 编辑们通常不会使用这些“slu”“的最佳名称，他们不会明智地选择它们。
• 许多项目属于（逻辑上）几个类别，所以为什么要限制它们（技术上）到一个类别？

更好的设计项URL由IDS（即/项目/ 435 /）

• IDS是稳定的（由DB产生的，而不是由编辑器中编辑），所以URL代表一个更大不随时间变化的机会
• 它们不公开（或依赖）数据库中对象的组织，如urls的category/item_name风格。如果您更改底层设计（对象结构）以允许某个项目属于多个类别，该怎么办？该类别/项目网址突然不再有意义了;你会改变你的网址设计，旧的网址可能无法工作了。

标签比类别更好。也就是说，允许一个项目属于几个类别比向每个项目分配一个类别更好。

Answer 9

与治疗既作为 目标的问题是如何区分它们 （如I中所述）。在最坏的情况下， 的情况是，你首先打你的 数据库，看看是否有一个类别 满足路径，如果它不 不然，你检查是否有一个 产品。问题是 对于每条产品路径，您将 最终对 数据库进行无用的调用，以确保它不是 类别。

那么是什么？没有必要在产品和类别之间做出硬性区分，至少在URI中是这样，除了对额外数据库调用的性能问题。如果这对你来说真的很重要，请考虑以下两条建议：

1. 大多数页面浏览量大概是产品，而不是类别。因此，首先对产品进行检查可以最大限度地减少数据库查找时需要加倍的频率。
2. 将代码添加到您的应用程序以显示生成每个页面所用的时间，然后用秒表出去到最近的网吧（而不是您的内部局域网！）。从你的网站上提出一些页面，并花时间来看看每个页面出现的时间。减去生成页面所用的时间。还要比较生成一个数据库查找页面与两个数据库查找页面所花费的时间。然后问问自己，什么时候总共需要1-2秒才能建立网络连接，生成内容并下载内容，是否花费额外的0.05秒或更少的时间用于额外的数据库查找？

优化它在哪里很重要，比如制作对人类友善的URL（如Chris Lloyd的回答）。不要浪费时间试图削减百分之一的最后一部分。