友好的网址方案？答案

【问题标题】：Friendly url scheme?友好的网址方案？
【发布时间】：2010-09-11 21:05:52
【问题描述】：

我上周设置的scraper service 缺少的许多东西之一是漂亮的 URL。现在，用户参数正在通过 ?u= 传递到脚本中，这是一个惰性 hack 的症状（脚本确实如此）。然而，我一直在考虑重做它，我想获得一些关于可用选项的反馈。现在有两个页面，更新和图表，为用户提供信息。这是我想出的两种可能性。 “1234”是用户ID号。由于技术原因，很遗憾无法使用用户名：

http:///update/1234
http:///chart/1234

或

http:///1234/update
http:///1234/chart

从概念上讲，选项 #1 是使用用户 ID 调用更新。选项 #2 是提供一个动词来操作用户 ID。

从一致性的角度来看，哪个更有意义？

提到的另一个选项是

http:///user/1234/update
http:///user/1234/chart

这为与特定用户无关的页面提供了空间。即

http:///stats

【问题讨论】：

标签： url friendly-url semantics

【解决方案1】：

如果您采用此方案，则可以轻松阻止（行为良好的）机器人爬取您的网站：

 http://< tld >/update/1234
 http://< tld >/chart/1234

这是因为您可以设置一个 /robots.txt 文件来包含：

 Disallow /update/
 Disallow /chart/

对我来说，这是一个很好的奖励，但经常被忽视。

【讨论】：

【解决方案2】：

我倾向于以用户 ID 开头——选项 #2——因为（存在的）目录结构是对用户数据的两个不同功能。是用户的图表，也是用户的更新。

不过，这只是一个小问题，不知道是否有计划对这件事的功能进行重大扩展。

未来的一切是否都将成为个人用户的附加功能 foo 和 bar 和 baz？如果是这样，由于上述原因，选项 #2 变得更有吸引力 - 用户 ID 是核心数据，从语义上开始是有意义的。
您要添加非用户驱动的功能吗？以标题目录开头可能会有意义 - /user/1234/update、/user/1234/chart、/question/45678/activity、/question/45678/stats 等。

【讨论】：

我不认为功能会增加很多，因为页面的目标是提供 StackOverflow 本身缺乏的功能。还有一些其他尚未公开的脚本用于处理服务的整体统计信息。你的 /user/1234/verb 很有吸引力。

【解决方案3】：

选项 #1 匹配常见的 ASP.NET MVC 示例。 Model View Controller 模型中的一些示例具有 {controller}/{action}/{id} 形式。 .NET 3.5 quickstart on routing 有一个表格显示了一些有效的路由模式：

路线定义 -- 匹配网址示例

{控制器}/{动作}/{id} -- /产品/节目/饮料

{table}/Details.aspx -- /Products/Details.aspx

博客/{action}/{entry} -- /blog/show/123

{reporttype}/{year}/{month}/{day} -- /sales/2008/1/5

{语言环境}/{动作}
-- /zh-CN/show

{语言}-{国家}/{行动}
-- /zh-CN/show

【讨论】：

实际上它与您找到的演示相匹配。 MVC 与 URL 编写器无关。
已更新以包含其他选项。谢谢你的收获。

【解决方案4】：

我个人喜欢这种风格，因为它使用户保持不变，但让您对他们有具体的了解。

http:///1234/update
http:///1234/chart

如果您采用其他方式，我希望能够看到 /update 或 /chart 下的所有内容，然后按用户缩小范围。

【讨论】：

【解决方案5】：

选择后者； URL 意味着是分层的（或者，至少，用户以类似于本地目录路径的方式读取它们）。这里的重点是对特定用户的不同看法，因此“用户”是更笼统的概念，应该首先出现。

【讨论】：

【解决方案6】：

我刚刚回答了"How do you structure your URL routes?" 的问题，并表达了我对使 URL 具有 RESTful、可破解性和用户友好性的看法。我认为链接比在这个问题中写类似的东西更好，因此链接。

【讨论】：

【解决方案7】：

我同意从上下文的角度来看，应用程序后面的参数对我来说比项目的代理键和项目的上下文更有意义。最终，我会建议你编程哪个更自然。

【讨论】：

#1 更容易，因为我使用 MultiViews 和 Apache 将动词转换为脚本名称。但是，如果以另一种方式引用它更有意义，我可以得到一些工作。

【解决方案8】：

约定说对象/动词/ID，所以应该是：

http:///user/update/1234

（我刚刚注意到这与您更新的问题相符：）

所以是的，#3 是最好的选择。

这支持您提到的非用户操作（stats/），以及多用户操作：

http:///user/list/

【讨论】：

【解决方案9】：

如果有列出用户的方法，我会介绍一个用户细分：

http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart

如果您只能看到自己的详细信息，即用户彼此不可见，则不需要用户 ID，因为您可以从会话中推断出来，在这种情况下：

http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart

【讨论】：