你将如何设计一个可破解的网址

Question

想象一下，您有一组产品类别组织在一个漂亮的树形层次结构中，并且您想提供可破解的 url 来浏览这些。你可以这样做

/catalog/categorya/categoryb/categoryc

然后您可以很容易地确定您应该为哪个类别列出产品（请注意，需要完整的 URL，因为您可以拥有名称相同但位于层次结构中不同位置的类别）

现在在其中添加产品信息的好方法是什么？举个例子，你想显示这个类别的产品 Oblivion

/catalog/games/consoles/playstation/adventure

在网址末尾添加产品很诱人

/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

的类别

到目前为止，后缀解决方案看起来是我能想到的最用户友好的方法，但我不喜欢必须使用扩展名

您对此有何看法？

Answer 1

将两者都视为的问题 目标是如何区分它们 （就像我描述的那样）。在最坏的情况下 场景是你先打你的 数据库查看是否有类别 满足路径，如果它 那么你不检查是否有 产品。问题是 对于每个产品路径，您将 最终打了一个无用的电话 数据库以确保它不是 类别。

那又怎样？没有必要在产品和类别之间进行严格区分，至少在 URI 中，除了可能对额外数据库调用的性能问题。如果这对您来说真的很重要，请考虑以下两个建议：

1. 大多数页面浏览量可能是产品，而不是类别。因此，首先检查产品将最大限度地减少您需要加倍进行数据库查找的频率。
2. 向您的应用添加代码以显示生成每个页面所用的时间，然后带着秒表前往最近的网吧（不是您的内部 LAN！）。从您的网站上调出一些页面，并确定每个页面需要多长时间。减去生成页面所花费的时间。还比较生成一个数据库查找页面和两个数据库查找页面所花费的时间。然后问问自己，当建立网络连接、生成内容和下载内容总共需要 1-2 秒时，是否花费额外的 0.05 秒或更短的时间进行额外的数据库查找真的很重要?

优化重要的地方，例如制作对人类友好的 URL（如 Chris Lloyd 的回答）。不要浪费你的时间试图削减最后可能的百分之一。

Answer 2

虽然与销售游戏无关，但我的卑微经历告诉我：

• 编辑们通常不会为这些“蛞蝓”使用最好的名字，他们没有明智地选择它们。
• 许多项目（在逻辑上）属于多个类别，那么为什么要将它们（从技术上）限制为一个类别？

通过 id 更好地设计项目 url，（即 /item/435/ ）

• id 是稳定的（由 db 生成，编辑器不可编辑），因此 url 有更大的机会不会随着时间的推移而改变
• 它们不会像 url 的 category/item_name 样式那样公开（或依赖）数据库中对象的组织。如果您更改底层设计（对象结构）以允许项目属于多个类别怎么办？类别/项目网址突然不再有意义；您将更改您的网址设计，旧网址可能不再适用。

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

Answer 3

一个问题是，您的用户对“以良好的树形层次结构组织的一组产品类别”的概念可能与您的概念相符。 这是 David Weinberger 的“Everything is Miscellaneous”的谷歌技术演讲，其中包含一些关于分类的有趣想法：

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

Answer 4

让我们剖析您的网址，使其更加干燥（不重复）。这是您的开始：

/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 的 slug：

/1234-oblivion

Answer 5

我喜欢 /videogames/consolename/genre/title" 并使用 / 的数量来区分类别或产品。我唯一担心的是多（或难以区分）类型。我强烈建议不要标题上的扩展名。您也可以执行类似 videogames(.php)?c=x360;t=oblivion; 之类的操作，然后猜测缺少的信息，但是我喜欢 / 方法，因为它看起来更整洁。为什么要添加流派？它可能更容易使用标题的第一个字母或只是做视频游戏/控制台/标题/

Answer 6

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

/product/1234/oblivion --> 直接页面
/product/oblivion --> /product/1234/oblivion 如果 oblivion 是一个独特的产品，
                  --> ~ 如果遗忘不是一个独特的产品，那么歧义页面。

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

/categories/79/adventure --> 游戏机冒险游戏
/categories/75/games --> 主机游戏页面
/categories/76/games --> playstation 游戏页面
/categories/games --> 消歧义页面。

否则，虽然 看起来 可破解的长 URL，但需要您正确获取所有节点元素才能破解它。

以php.net为例

php.net/str_replace --> 转到 http://nz2.php.net/manual/en/function.str-replace.php

而且这个模型非常容易破解，人们一直在盲目地使用它。

注意：W3C 认为 .html 后缀在功能上无意义且多余，应避免在 URL 中使用。

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

Answer 7

@Lou Franco 是的，任何一种方法都需要一个强大的后备机制并将其发送到某种建议页面或搜索引擎都是不错的选择

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

@some 是的，分隔符可能是一种可能的解决方案，但 .html 后缀更易于使用且广为人知。

Answer 8

如果您将不同的部分视为目标，那么产品本身就是另一个目标。 所有目标都应该可以通过 target.html 访问，或者只能通过目标访问。

目录/游戏/控制台/playstation.html
目录/游戏/游戏机/游戏机

目录/游戏/控制台/playstation/adventure.html
目录/游戏/游戏机/游戏机/冒险

目录/游戏/控制台/playstation/adventure/oblivion.html
目录/游戏/控制台/游戏机/冒险/遗忘

等等以使其保持一致。

我的 5 美分...

Answer 9

这些看起来都很好（除了冒号的那个）。

关键是当他们猜错时该怎么办——不要将他们发送到 404——相反，将你不知道的单词发送到该单词的搜索页面结果中——甚至更好如果您可以在那里进行拼写检查。