友好的网址方案?

时间:2020-03-06 14:31:09  来源:igfitidea点击:

上周设置的刮板服务一直缺少的许多内容之一就是漂亮的URL。现在,用户参数正在使用?u =传递到脚本中,这是懒惰黑客的一种症状(脚本当然是)。但是,我一直在考虑重做它,我想获得有关可用选项的一些反馈。现在有两个页面,即更新和图表,它们向用户提供信息。这是我想到的两种可能性。 " 1234"是用户标识号。出于技术原因,不幸的是不能使用用户名:

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

或者

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

从概念上讲,选项1是使用用户ID调用更新。选项#2提供了动词来对用户ID进行操作。

从一致性的角度来看,哪个更有意义?

提到的另一个选择是

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

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

  • http:// <tld> / stats

解决方案

我个人喜欢这种样式,因为它可以使用户保持不变,但是可以让我们对他们有特定的了解。

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

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

选项1与常见的ASP.NET MVC示例匹配。模型视图控制器模型中的某些示例的格式为{controller} / {action} / {id}。路由的.NET 3.5快速入门中有一张表,其中显示了一些有效的路由模式:

路线定义
-匹配网址示例

{controller} / {action} / {id}
-/产品/展示/饮料

{table} /Details.aspx
-/产品/Details.aspx

博客/ {action} / {entry}
-/博客/节目/ 123

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

{locale} / {action}
-/ zh-CN / show

{language}-{country} / {action}
-/ zh-CN / show

从上下文的角度来看,我同意,对我而言,应用程序后跟参数的意义比项目的替代键以及后跟事物的上下文的意义大得多。最终,我建议我们更自然地编程。

我会倾向于使用userid -option#2-进行引导,因为(存在的内容)目录结构是用户数据上的两个不同功能。这是用户的图表,以及用户的更新。

不过,这是一个非常小的要点,而不知道是否有计划对该功能进行重大扩展。

  • 对于个人用户,将来是否还会有其他功能foo和bar和baz?如果是这样,由于上述原因,选项#2更具吸引力-用户ID是核心数据,从语义上讲,从某种意义上讲是有意义的。
  • 我们是否要添加非用户驱动的功能?那么,以标头目录开头可能很有意义-/ user / 1234 / update,/ user / 1234 / chart,/ question / 45678 / activity,/ question / 45678 / stats等。

与后者一起去; URL应该是分层的(或者至少用户类似于本地目录路径那样阅读URL)。这里的重点是特定用户的不同观点,因此"用户"是更一般的概念,应首先出现。

约定表示对象/动词/ ID,因此应为:

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

(我刚刚发现与我们更新的问题匹配:)

是的,#3是最好的选择。

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

http:// <tld> / user / list /

我只是回答了"我们如何构造URL路由?"这个问题。我对使URL RESTful,可入侵且用户友好的观点。我认为链接比在此问题中写类似的东西(因此称为链接)要好。

如果我们采用这种方案,则可以轻松地阻止(行为良好的)机器人抓取网站:

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

这是因为我们可以将/robots.txt文件设置为包含:

Disallow /update/
 Disallow /chart/

对我来说,这是一个很好的奖励,但常常被忽略。

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

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,因为可以从会话中推断出该用户ID,在这种情况下:

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