RESTful URL的好处

时间:2012-06-23 16:07:22

标签: rest

有什么好处
 http://www.example.com/app/servlet/cat1/cat2/item 

URL

结束

 http://www.example.com/app/servlet?catid=12345

URL

如果我们使用第一个网址会有任何问题,因为最初我们使用的是第一个网址并更改为第二个网址。这是在网站上不断变化的内容的背景下。这里的类别可以是无限的。

5 个答案:

答案 0 :(得分:3)

关于RESTful应用程序,您不应该关心URL模板。 “更好”的是应用程序更容易生成的那个。

关于索引和搜索引擎优化,抱歉,但搜索引擎不太可能理解你的超媒体API能够为其编制索引。

要更好地了解网址,请查看:

答案 1 :(得分:2)

一个区别是第二个URL没有命名类别,因此客户端代码和人类用户需要首先查找某个类别名称到数字映射页面,存储这些映射,一直使用它们,然后刷新遇到以前未知的类别时的列表等。给定第一个URL,即使项目页面没有提及它们,你也必须知道类别(但是网站可能仍然需要某个类别的列表)。

另一个区别是第一种格式编码两级分类,而第二种格式隐藏级别数。这可能会使事情变得更容易或更难,这取决于您希望深度(现在或稍后)的变量以及是否有人不恰当地将代码耦合到2级深度(例如,通过使用正则表达式解析URL以使用两个子组捕获类别)。当然,如果他们将自己结合到id->类别路径映射页面中列出的当前类别深度,也可能存在相同的问题....

答案 2 :(得分:2)

就搜索引擎优化而言,如果您希望搜索引擎the first is better assuming the category names are descriptive of the content将其编入索引。大多数引擎都支持与搜索查询匹配的URL。但是,如果类别名称可以更改,则可能需要保留301 redirects

答案 3 :(得分:2)

第一种形式将被搜索引擎更好地索引,并且更加缓存友好。后者既有优势(你可以减少服务器的负载)和缺点(你不一定意识到人们重新访问你的页面,页面更改可能不会立即传播给用户:必须要小心为实现这一点而采取的行动)。

第一种形式还需要(稍微)更重的处理才能从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标头请求。

答案 4 :(得分:2)

我们在这里所拥有的不仅仅是“更好”的索引,而是相关性。

因此,第一个URL会将您的页面标记为与主题更相关(假设页面/猫名称和主题之间的相关性)。

例如:假设我们都想为“红色耐克鞋”排名,说(为了简单起见)我们在除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%将导致)重复内容问题。使用参数时,您必须处理以下问题:

  • 对于不存在的catid会发生什么?
  • 是否有参数验证? (以及如何充分证明?)

等等。

那为什么选择第二个版本呢?因为有时候你没有选择......:)