为网站提供友好的URL与数据库ID的实际情况

24

我们有一个资源数据库，无论是产品，博客文章还是其他资源。我们需要为公共网站设计一个URL方案来解决它们。

这是绑定数据库ID的两个示例：

这是一个友好的示例：

（瞥见我在那里的浏览生活）

我喜欢友好的URL，因为当您将鼠标悬停在电子邮件或文档中或在电子邮件或文档中看到URL时，您会知道URL末尾的含义。SEO更好，或者曾经是。

重命名文档或产品时会发生什么？是因为它已更改（Wiki可能不会更改，但我们的资源可能会更改）还是由于输入错误，对吗？我们的资源非常技术性，冗长且容易出错。

另外，我们有一个数据库ID，它是一个数字。让我们来看一个使用假装租赁商店的视频地址的想法：

该ID很明显，并用于数据库查找中。精细。

滑动门不是唯一的，只是从视频标题生成的，可以在GET上进行验证，因此，如果输入了滑动门，但与文档287171中的内容不匹配，则会响应404。

或者，也许它可以忽略不计，如果有人关心的话，它允许人类将他们喜欢的东西粘在里面。因此，该URL也将起作用：

如前所述，验证友好部分的问题是重命名或拼写错误的问题。如果名称更改，并且确实发生在我们的域中，我们不想破坏那里的URL，那么我们应该：

  • 只是不验证友好部分。

  • 验证，但在数据库记录中添加友好零件的“历史记录”，以便任何以前的友好ID仍然有效！

欢迎您的想法和想法。

路加

web-applications  rest  web  websites  http 
— 卢克·普普利特（Luke Puplett）
source
11
即使是这个网站也使用了组合http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids（鉴于标题更改，使用了未经验证的版本，较短的“共享”链接也只是ID ：（http://programmers.stackexchange.com/q/255684/25768和用于徽章跟踪的用户ID）
— 棘手怪癖2014年
11
如果您的网址中有唯一的ID，那么我根本看不到您为什么要验证段状部分的原因。将其用于外观，而将其用于查找。
— thorstenmüller2014年
如果你们中的任何一个想要给出正确的答案，我都会投票赞成，以便您获得要点。我将投票通过，并在几天之内将投票结果授予投票最多的人。
— 路加·普普利特
1
— 蚊蚋
3
以前从来都不知道这个词。我一定在一块石头上。吉迪特？
— 路加·普普利特

Answers:

6

将ID保留在URL中是最可靠的方法，并且如您所展示的，URL看起来仍然相对不错。

多个项目使用的另一个选项是保留以前使用的块的历史记录。标题更改时，您将更新该段，如果有人尝试查找过时的段，请在旧段的列表中搜索。这样，可以将旧的子段重用于新内容（或不取决于您的实现）。

WordPress做到了，而且friendly_id gem也是如此，后者可能是管理Rails友好ID的最常用的gem。

另外，尽管我喜欢外观漂亮的URL，但我认为重要的是要记住，这很可能是更多精通技术的用户使用的功能。一些浏览器甚至开始隐藏URL（或URL的一部分）。

— 姆比亚德
source
2
我一直在考虑这段历史。自发布问题以来，我注意到许多大型站点都有未选中的条目，您可以将其更改为任何内容。amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8作品。StackExchange很聪明，因为它可以“纠正”并重定向浏览器，以确保显示和共享正确的链接。
— 路加·普普利特
“子弹”对人们的用处不大，而对搜索引擎优化则更有用，因为“子弹”或“友好的URL”应具有与页面内容相关的关键字。高级用户不是您的网站中包含友好URL的理由。搜索引擎排名往往是主要原因。
— Greg Burghardt 2014年
我不同意。仅具有ID的网址很难使用；从它们的列表中很难记住您可能想要返回的列表。或者，在链接的另一端是否会有不适当的东西。Chrome浏览器的地址栏也会在URL的任何部分显示建议，这很有用。
— 路加·普普利特
1
@LukePuplett是的，我认为SE的处理URL的方法是最简单的方法。
— mbillard 2014年
@GregBurghardt唯一的区别是在点击率，用户会在友好的URL稍微点击：stackoverflow.com/questions/505793/...
— mbillard
3

过去我使用了两种不同的方案。

  1. /id/some-slug其中所述id用于查找，蛞蝓不。因此，the可以是任何东西。但是，当该段与实际段不匹配时，用户将被重定向到当前版本。

  2. /permalink对于某些情况，即使我们有一个可用的ID ，我们也不希望该URL中的id或该URL永远都不应更改（请参阅[1]和[2]）。当然，在这种情况下，用作查找。当前段和永久链接（第一个段）都存储在数据库中。permalink

无论采用哪种方式，您都无需在数据库中保留段记录的历史，这很快就会出现问题。

ps：在第二种情况下，您需要一些非常具体的路由来保留社会信用：

  • 如果需要，将用户重定向到当前（非永久链接）URL
  • 将固定链接用作社交按钮中的网址
  • 始终将Facebook搜寻器重定向到永久链接

再次参见[1]和[2]。

— 洛德
source
为什么会有问题？如果我保留ID和子弹等信息，则访问者将转到实际页面。对SEO有害吗？
— Jnanaranjan
您的意思是保留的历史吗？当有人想重新使用这种弹头时，您该怎么办？对于相同或另一个ID？您如何设计数据库和/或代码以防止多次重定向？您是否要在删除后隐藏存在的内容，并且重定向是否暴露先前的存在？所有这些都不是不可能的，但是它提出了各种各样的问题，而我只是设计地避免了。
— 罗德
我想说的是，如果ID存在于URL中，那么无论它是什么子类，它都将重定向到请求的页面。那么the的历史就没关系了。我同意这对Android来说是有问题的。
— Jnanaranjan
1
啊好吧。那就是我添加方案1的权利吗？还是您还有其他意思？
— 罗德
是。那是正确的。
— Jnanaranjan
2

重命名文档或产品时会发生什么？

为此设计了HTTP响应301（已移动）。如果有任何客户端使用旧的URI，则只需向他们发送新的URI，他们就可以重定向到该URI。

滑动门不是唯一的，只是从视频标题生成的，可以在GET上进行验证，因此，如果输入了滑动门，但与文档287171中的内容不匹配，则会响应404。

如果我正确遵循的话，这是重复的工作，那么您在同一URI中同时具有资源的名称标识符和ID。那没有任何目的。

如果您担心多部同名电影，可以将有关该电影的其他信息添加到URL中

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

要么 

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

话虽如此，但如果对您的数据模型有意义，则使用ID没什么问题，尤其是如果您要分组的唯一内容是视频。

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

客户端，无论是计算机用户还是人类用户，首先都不应该过分依赖URI结构，他们应该查看您返回的内容以找出要查找的资源。

明智的URI系统没有什么错，它使某人可以轻松地猜测资源的位置或基于共享属性（即2004年的所有电影）在结构中上下移动，但是您的系统不应依赖这样，如果您更改URI，则任何客户端都不应中断

或者换一种说法，您应该可以从

http://vidsyeah.com/video/studios/paramount/sliding_doors

至 

http://vidsyeah.com/video/12323

并且没有客户端应该中断，因为客户端应该查看的是内容而不是URL。

— 科马克·穆哈尔（Cormac Mulhall）
source
像乔恩（Jon）的回答一样，我认为您在考虑此问题时没有戴UX帽子。我想增加地址的可用性。请参阅我在问题中的评论：“我喜欢友好的URL，因为当您将鼠标悬停或在电子邮件或文档中看到URL末尾时，您会知道URL末尾有什么含义。对于SEO来说，它过去更好。”
— 路加·普普利特
2
为了抛出301，我需要能够查找正确的资源，因此我需要一个历史记录。
— 路加·普普利特
1
您将需要一个历史记录，但是如果您的站点的资源发生了变化，那还是一个好主意。
— Cormac Mulhall 2014年
友好的URI没有问题。我不会做这样的方案，即URI可以是任何东西，但如果末尾有ID，它仍然可以工作。但这并不能真正解决任何问题（用户仍然必须记住ID），并引入了一个令人困惑的URI方案（用户可能会合理地问为什么两个不同的URI（其中一个存在拼写错误，会使用相同的资源））
— Cormac Mulhall
1
如果您担心URI中的拼写错误，则通常的处理方法是在404错误页面中针对拼写错误的URL建议使用URI。您可以进行单词模式搜索，并返回您认为用户正在寻找的内容。
— Cormac Mulhall 2014年
0

从RESTful的角度来看，URI应该遵循可预见的并固定层次结构以增强可用性。

这将使它们更容易被消费者使用。如果您的数据具有关系，则将需要某种层次结构。

看起来该方案是： \video\[name]\[id]

如果该名称未用于任何进一步的分类，则可以将其取而代之 \video\[id].

但是，如果您希望对视频进行分类，那么名称可能会有用。

例子：

  • \ video \ SwingingDoors \ 123
  • \ video \ SwingingDoors \ 124
  • \ video \ SlidingDoors \ 125
  • \ video \ SlidingDoors \ 126

这实际上是对访问建模的设计决定。

— 乔恩·雷诺
source
我认为您正在从API /站点信息体系结构PoV考虑这一点。我希望引入一个生成的友好URL部分，以帮助人类和SEO。显然，这是很平常的事情，并且取名为“ slug”。该名称未用于分类，而是通过添加URL（URL）和我们的网站/品牌来添加（而不是删除）该名称，以使用户体验更好。
— 路加·普普利特
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.