友好的URL方案?

我会倾向于以user i d——选项2——开头,因为(存在的)目录结构是用户数据上的两个不同函数。这是用户的图表和用户的更新。

不过,这是一个很小的问题,不知道是否有计划显著扩展这个功能。

• 是否所有的功能都将是面向个人用户的foo、bar和baz附加功能?如果是这样的话,选项2会因为上面的原因变得更有吸引力——用户ID是核心数据,从语义上讲从它开始是有意义的。
• 是否要添加非用户驱动的功能?以头目录开头可能很有意义,然后--/user/1234/update,/user/1234/chart,/question/45678/activity,/question/45678/stats等。

如果你采用这个方案,就很容易阻止(行为良好的)机器人在你的网站上爬行:

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

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

 Disallow /update/
 Disallow /chart/

对我来说,这是一个经常被忽视的好的奖金。

选项1与常见的ASP.NET MVC示例匹配。一些示例位于 Model View Controller 模型具有控制器/动作/ID的形式。这个 .NET 3.5 quickstart on routing 有一个表显示一些有效的路由模式:

路由定义 --匹配的URL示例

控制器/动作/ID --/产品/表演/饮料

表/详细信息.aspx --/产品/详情.aspx

blog/action/entry --/博客/节目/123

报表类型/年/月/日 --/销售/2008/1/5

区域/行动
-美国

语言-国家/行动
-美国

我个人喜欢这种风格,因为它保持了用户的一致性,但给了你对它们的特定洞察力。

• http://lt;tld>/1234/更新
• http://lt;tld>/1234/图表

如果换一种方式,我希望能够看到/update或/chart下的所有内容,然后按用户缩小范围。

使用后一种方法;URL应该是分层的(或者,至少,用户通过类似于本地目录路径的方式读取它们)。这里的重点是针对特定用户的不同视图,因此“用户”是更一般的概念,应该首先出现。

我刚刚回答了这个问题 "How do you structure your URL routes?" 我的意见是让网址更安全,更容易被黑客攻击和用户友好。我认为链接比在这个问题中写类似的东西要好,因此链接。

我同意从上下文的角度来看,应用程序后面跟着参数对我来说比项目的代理键后面跟着项目是什么的上下文更有意义。最后,我建议您选择哪一种更自然的程序。

约定表示对象/动词/ID,所以应该是:

http://lt;tld>/user/update/1234

(我刚刚注意到与您更新的问题匹配:)

所以是的,3是最好的选择。

这支持您提到的非用户操作(stats/),以及多用户操作:

http://lt;tld>/user/列表/

如果有列出用户的方法,我将介绍一个用户段:

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