2

想象一下，您有一组产品类别组织在一个漂亮的树形层次结构中，并且您想提供可破解的 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的类别

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

您对此有何看法？

4

9 回答 9

10

深沉的道路让我厌烦。他们很难分享。


/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

于 2008-11-22T09:26:05.810 回答
6

让我们剖析您的 URL，以便更加干燥（不重复）。这是您开始的内容：

/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
于 2008-11-22T10:37:30.500 回答
1

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

关键是当他们猜错时该怎么办——不要将它们发送到 404——相反，将你不知道的词发送到该词的搜索页面结果——如果可以的话，效果会更好拼写检查。

于 2008-11-14T13:07:15.537 回答
1

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

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

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

目录/游戏/控制台/playstation/adventure/oblivion.html
目录/游戏/控制台/playstation/adventure/oblivion

依此类推，使其保持一致。

我的5美分...

于 2008-11-14T13:08:19.937 回答
1

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

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

于 2008-11-23T02:08:08.110 回答
0

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

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

@some 是的，分隔符可能是一种可能的解决方案，但是 .html 后缀更加用户友好并且众所周知。

于 2008-11-14T13:32:13.240 回答
0

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

于 2008-11-22T10:01:25.910 回答
0

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

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

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

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

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

于 2008-11-23T03:07:00.410 回答
0

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

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

  1. Most page views will presumably be on products, not categories. So doing the check for a product first will minimize the frequency with which you need to double up on the database lookups.
  2. Add code to your app to display the time taken to generate each page, then go out to the nearest internet cafe (not your internal LAN!) with a stopwatch. Bring up some pages from your site and time how long each takes to come up. Subtract the time taken to generate the page. Also compare the time taken to generate one-database-lookup pages vs. two-database-lookup pages. Then ask yourself, when it takes maybe 1-2 seconds total to establish a network connection, generate the content, and download the content, does it really matter whether you're spending an extra 0.05 second or less for an additional database lookup or not?

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

于 2008-11-23T04:02:18.567 回答