要遵循的 url 参数命名约定或标准是啥
Posted
技术标签:
【中文标题】要遵循的 url 参数命名约定或标准是啥【英文标题】:What are the url parameters naming convention or standards to follow要遵循的 url 参数命名约定或标准是什么 【发布时间】:2010-10-08 19:25:46 【问题描述】:是否有任何要遵循的 Url 参数的命名约定或标准。我一般使用userId
或itemNumber
之类的驼色外壳。当我即将开始一个新项目时,我正在搜索是否有任何东西,但找不到任何东西。我不是从语言或框架的角度来看这个,而是作为一个通用的网络标准。
【问题讨论】:
一般趋势是从 URL 中删除技术细节,例如.php
。除此之外,人们还想出了各种“语义”的 URL 结构。没关系。
【参考方案1】:
没有我知道的标准。请注意 IE 的 URL length limit,共有 2,083 个字符。
【讨论】:
【参考方案2】:就像我没有听说过任何约定的其他答案一样。
我会坚持的唯一“标准”是使用对搜索引擎更友好的做法,即使用 URL 重写器。
【讨论】:
【参考方案3】:没有我知道的标准,大小写无关紧要。
但是,在您的应用程序(网站)中,您应该坚持自己的标准。如果没有别的,为了你自己的理智。
【讨论】:
【参考方案4】:我使用小写。根据您使用的技术,QS 要么区分大小写(例如 PHP),要么不区分大小写(例如 ASP)。使用小写可以避免可能的混淆。
【讨论】:
【参考方案5】:我建议阅读 Tim Berners-Lee 的 Cool URI's Don't Change 以深入了解这个问题。如果您在 URI 中使用参数,最好重写它们以反映数据的实际含义。
所以不要有以下内容:
/index.jsp?isbn=1234567890
/author-details.jsp?isbn=1234567890
/related.jsp?isbn=1234567890
你应该有
/isbn/1234567890/index
/isbn/1234567890/author-details
/isbn/1234567890/related
它创建了一个更明显的数据结构,这意味着如果您更改平台架构,您的 URI 不会改变。如果没有上述结构,
/index.jsp?isbn=1234567890
变成
/index.aspx?isbn=1234567890
这意味着您网站上的所有链接现在都已损坏。
一般来说,您应该只在用户可以合理地期望生成他们正在检索的数据时才使用查询字符串,例如搜索。如果您使用查询字符串从数据库中检索不变的资源,请使用 URL 重写。
【讨论】:
这根本不能回答问题。原始帖子询问是否有查询字符串参数的命名约定。正如您自己提到的,当您搜索或过滤数据时,查询字符串是合适的 (***.com/a/17999251/1424734),那么为什么要正确使用它们呢? 请回答有关骆驼大小写与查询字符串参数的连字符命名的问题【参考方案6】:URI 的标准由RFC2396 定义。 URL 标准化部分之后的任何内容都留给您。
您可能只想根据您使用的框架遵循特定的参数约定。 大多数情况下,您甚至不会真正关心,因为这些不在您的控制之下,但当它们控制时,您可能希望至少保持一致并尝试生成用户友好的位:
很短, 如果它们旨在供用户直接访问,它们应该易于记忆, 不区分大小写(可能很难,具体取决于服务器操作系统)。 关注SEO guidelines and best practices,他们可能对你有很大帮助。我想说的是,在呈现 URL 时,整洁和用户友好是值得称赞的目标。 *** 在这方面做得相当不错。
【讨论】:
我同意你关于 url 的样式,并避免参数,当我看到 Atlassians 的 Jira 和 Bamboo 有它时,我首先对这种样式感兴趣,使 url 看起来很简单。在 Apache 上可以设置一些重写规则。你知道 IIS 和 .NET 的相似之处吗 根据RFC 3986, 6.2.2.1:假定其他通用语法组件区分大小写。那么为什么要生成不区分大小写的位呢? @MartijnBurger 因为最终用户手动输入 URL 可能不希望字符串区分大小写。最小意外原则。以上是关于要遵循的 url 参数命名约定或标准是啥的主要内容,如果未能解决你的问题,请参考以下文章