简而言之,为什么要使用类似http://stackoverflow.com/badges/6/supporter
的东西而不是“更简单”的东西(并且主观上是这样)http://stackoverflow.com/badges/6/
。
即使在我自己的网站上,我也只是使用 /post/6/ 来引用帖子(通过 ID,即使我仍然存储一个 slug。)而不是/post/6/small-rant-on-urls
,并且在某些情况下,它们会变得更加荒谬,更是如此比真的必要。
简而言之,为什么要使用类似http://stackoverflow.com/badges/6/supporter
的东西而不是“更简单”的东西(并且主观上是这样)http://stackoverflow.com/badges/6/
。
即使在我自己的网站上,我也只是使用 /post/6/ 来引用帖子(通过 ID,即使我仍然存储一个 slug。)而不是/post/6/small-rant-on-urls
,并且在某些情况下,它们会变得更加荒谬,更是如此比真的必要。
搜索引擎优化将是其中之一,并使 URL 对人类更具可读性。搜索引擎通常喜欢你的 URL、Title 和 H2 来包含页面的“主题”。
如果你两者都在那里,那么你可以手动输入 /ID 并通过重写自动带到“华丽”的 URL .. 节省你的手指 :)
因为如果你不小心,你可能会得到重复。我想堆栈溢出添加了 ID,因为考虑到创建的帖子数量,重复的可能性很大。
其他系统可能选择不使用 URL 中的 ID - 例如,博客系统可能不需要。
如果您有用户生成的内容会导致创建一个包含帖子 ID 的新 URL,这是一个更好的主意。如果创建新 URL 的唯一方法是通过管理员类型访问,那么只要检查重复项,您就可以不用它。
在内容的所有链接中添加 slug有助于搜索引擎,因为搜索引擎通常会使用 URL 本身中的单词来帮助索引内容。
在 url 中包含 id 的原因是它可以更容易地在幕后从数据库中检索正确的文章,因为可以对 ID 而不是文章的标题执行查找。
包含文章完整标题的原因是,Google 会为文件名中匹配的搜索词提供大量奖励积分。
URL 是 Web 用户界面的一部分。
有一项关于搜索引擎使用的眼动追踪研究发现,人们花费24% 的凝视时间查看搜索结果中的 URL。
搜索者在评估目的地的可信度和有用性时对 URL 特别感兴趣。如果 URL 看起来像垃圾,人们就不太可能点击该搜索命中。另一方面,如果 URL 看起来像页面会解决用户的问题,那么他们更有可能点击。
@格雷格休吉尔
在内容的所有链接中添加 slug 有助于搜索引擎,因为搜索引擎通常会使用 URL 本身中的单词来帮助索引内容。
我应该澄清一下:我的意思是同时包含 id和slug 的 URL。我只是看不出有类似/post/1/la-la-la-la-text-hahahaha
vs/post/1/
或 /post/la-la-la-la-text-hahahaha
之类的东西的意义,因为第一个可以在没有多余文本的情况下工作。
通过 id 在博客中获取帖子可能比通过 slug 更快,因此将 id 用于 SQL 查询,将 slug 用于搜索引擎 (SEO)。
https://stackoverflow.com/users/58163/movaxes65675
我喜欢 /post/la-la-la-la-text-hahahaha 类型,我可以记住网址,知道帖子的标题是什么(在实际加载网站之前)。不太喜欢 /post/1/ 它对我来说没有任何意义,但帖子 #1 (不利于营销?)
编辑: id 也有助于避免像 andybaird 指出的重复
嗯,首先应该指出,“Web 2.0 风格的 URL”实际上是称为REST的东西的一部分。这些 URL 有时称为 RESTful URL。声称的好处是:
- 由于支持缓存表示,因此提供了改进的响应时间并减少了服务器负载;
- 通过减少维护会话状态的需要来提高服务器的可伸缩性。这意味着可以使用不同的服务器来处理会话中的不同请求;
- 与其他方法相比,需要编写更少的客户端软件,因为单个浏览器可以访问任何应用程序和任何资源;
- 较少依赖供应商软件和机制,这些软件和机制在 HTTP 之上添加了额外的消息传递框架;
- 与替代通信方法相比,提供等效的功能;
- 由于在表示中使用了超链接,因此不需要单独的资源发现机制;
- 提供比 RPC 更好的长期兼容性和可演化特性。这是因为:
- 文档类型(如 HTML)在不破坏向后或向前兼容性的情况下发展的能力;和
- 资源在不放弃或减少对旧内容类型的支持的情况下添加对定义的新内容类型的支持的能力。