有什么好处
http://www.example.com/app/servlet/cat1/cat2/item
网址
超过
http://www.example.com/app/servlet?catid=12345
网址
如果我们使用第一个 URL 会不会有任何问题,因为最初我们使用第一个 URL 并更改为第二个 URL。这是在网站上不断变化的大量内容的背景下。这里的类别可以是无限的。
有什么好处
http://www.example.com/app/servlet/cat1/cat2/item
网址
超过
http://www.example.com/app/servlet?catid=12345
网址
如果我们使用第一个 URL 会不会有任何问题,因为最初我们使用第一个 URL 并更改为第二个 URL。这是在网站上不断变化的大量内容的背景下。这里的类别可以是无限的。
对于 RESTful 应用程序,您不应该关心 URL 模板。“更好”的是应用程序更容易生成的那个。
关于索引和 SEO,很抱歉,但搜索引擎不太可能理解您的超媒体 API 以对其进行索引。
为了更好地理解 URL,请查看:
一个区别是第二个 URL 没有命名类别,因此客户端代码和实际上的人类用户需要首先查找一些类别名称到数字的映射页面,存储这些映射,一直使用它们,然后刷新列表遇到以前未知的类别等。给定第一个 URL,即使项目页面未提及它们,您也一定知道类别(但站点可能仍然需要某个类别的列表)。
另一个区别是第一种格式编码了两个级别的分类,而第二种隐藏了级别的数量。这可能会使事情变得更容易或更难,具体取决于您希望深度的可变性(现在或以后)以及是否有人不恰当地将代码耦合到 2 级深度(例如,通过使用正则表达式解析 URL,使用两个子组捕获类别)。当然,如果它们将自身耦合到 id->category-path 映射页面中列出的当前类别的深度,则可能存在相同的问题......
就 SEO 而言,如果这是您希望搜索引擎索引的内容,那么首先最好假设类别名称描述了它们下的内容。大多数引擎偏爱与搜索查询匹配的 URL。但是,如果类别名称可以更改,您可能需要在更改时维护301 重定向。
第一种形式将更好地被搜索引擎索引,并且对缓存更友好。后者既是优势(您可以减少服务器上的负载)也是劣势(您不一定知道有人重新访问您的页面,并且页面更改可能不会立即传播给用户:必须小心一点为实现这一目标而采取的措施)。
第一种形式还需要(有点)更繁重的处理才能从 URL 中获取所需的项目。
如果您可以控制 URL 语法,我建议您这样做:
http://www.example.com/app/servlet/cat1/cat2/item/12345
或者更好的是,通过 URL 重写,
http://www.example.com/cat1/cat2/item/12345
其中 12345 是资源 ID。然后,当您访问数据时(无论如何您都会这样做),能够快速完成;您只需验证记录是否与 cat1、cat2 和 item 匹配。尝试使用页面缓存设置并确保发送 ETag(可能基于 ID?)和 Last-Modified 标头,以及检查 If-Modified-Since 和 If-None-Match 标头请求。
我们在这里所拥有的不是“更好”索引的问题,而是相关性的问题。
因此,第一个 URL 会将您的页面标记为与主题更相关(假设页面/猫名称和主题之间的相关性)。
例如:假设我们都想为“Red Nike shoes”排名,假设(为简单起见)我们都在除 URL 之外的所有 SEO 因素上获得相同的“分数”。在第一种情况下,URL 可以是http://www.example.com/app/servlet/shoes/nike/red-nice
并且在第二种情况下http://www.example.com/app/servlet?itemid=12345
。
只需查看两个字符串,您就可以直观地感觉到哪一个更相关……第一个告诉您“哎呀,是的,我很喜欢红色耐克鞋”,而第二个有点咕哝“红色耐克鞋?你是说项目代码 12345 吗?”
此外,在 URL 中包含部分 KW 将帮助您获得更多相关性,还可以帮助您赢得“长尾”目标而无需太多工作。(有时只在 URL 中有 KW 就足够了)
但问题更深。第二种类型的 URL 包括参数,这些参数可能(99.9% 会)导致重复内容问题。使用参数时,您必须处理以下问题:
等等。
那么为什么选择第二个版本呢?因为有时您别无选择... :)