连字符、下划线或驼峰式作为 URI 中的单词分隔符？答案

【问题标题】：Hyphen, underscore, or camelCase as word delimiter in URIs?连字符、下划线或驼峰式作为 URI 中的单词分隔符？
【发布时间】：2012-05-05 08:12:01
【问题描述】：

我正在为 Intranet 应用程序设计基于 HTTP 的 API。我意识到这在总体方案中是一个很小的问题，但是：我应该使用连字符、下划线还是驼峰式来分隔 URI 中的单词？

这是我最初的想法：

驼峰式

如果服务器不区分大小写可能会出现问题
似乎在查询字符串键 (http://api.example.com?**searchQuery**=...) 中有相当广泛的使用，但在其他 URI 部分没有

连字符

比其他替代品更美观
似乎被广泛用于 URI 的路径部分
在野外从未见过带连字符的查询字符串键
可能更适合 SEO（这可能是一个神话）

下划线

编程语言可能更容易处理
一些流行的 API（Facebook、Netflix、~~StackExchange~~ 等）在 URI 的所有部分都使用下划线。

我倾向于在所有内容中使用下划线。大多数大玩家都在使用它们这一事实令人信服（参见https://stackoverflow.com/a/608458/360570）。

【问题讨论】：

从我读过的所有内容来看，您应该使用连字符，但下划线 似乎更易于管理。
我相信 连字符 曾一度更适合 SEO。现在这可能不是真的，但是有很多人采用它，因此它被更广泛地接受为最佳实践。另一方面，下划线在后端编程中可能更容易处理。我使用 PHP，因此在函数名中使用下划线比使用连字符要容易得多。 camelCase 可能是最容易实现的，但阅读起来往往很困难。最后，我认为你说你从未见过hyphenated query string in the wild 是对的。这通常是 camelCase 的时间。
根据这个问题，下划线不是一个有效的选项：stackoverflow.com/questions/3641722/…
Are there any naming convention guidelines for REST APIs?的可能重复
你提到了流行的API，我想补充一个：谷歌。据我所见，谷歌在单词之间根本没有使用任何东西（例如，查看谷歌地图距离矩阵 API）。

标签： rest url uri restful-url

【解决方案1】：

您应该在可抓取的 Web 应用程序 URL 中使用连字符。为什么？因为连字符分隔单词（以便搜索引擎可以索引单个单词），并且连字符不是word character。下划线是单词字符，意味着它应该被视为单词的一部分。

在 Chrome 中双击这个：camelCase
在 Chrome 中双击：under_score
在 Chrome 中双击这个：连字符

看看 Chrome（我听说 Google 也制作了一个搜索引擎）如何只认为其中一个是两个词？

camelCase 和 underscore 也要求用户使用 shift 键，而 hyphenated 不需要。

因此，如果您应该在可抓取的 Web 应用程序中使用连字符，为什么还要费心在 Intranet 应用程序中做一些不同的事情呢？少一件事要记住。

【讨论】：

我在 Windows 7 上的 Firefox 24 认为 'hyphen-ated' 是两个词。
'under_score' 的行为相同。
查询字符串的任何约定，例如?event_id=1 或?eventId=1???
@user2727195 虽然 URL 区分大小写，但最好的做法是尽可能使用小写，因为这样可以消除输入错误的可能性。
互动回答:)

【解决方案2】：

REST API 的标准最佳做法是使用连字符，而不是驼峰式或下划线。

这来自 Oreilly 的 Mark Masse 的“REST API 设计规则手册”。

另外，请注意 Stack Overflow 本身在 URL 中使用连字符：.../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

和 WordPress 一样：http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually

【讨论】：

如果您查看 REST API 设计规则手册中关于查询字符串指南的章节，您会注意到指南因规则部分而异。查询字符串中的大小写没有明确的规则，但您会发现查询字符串部分中的所有示例中的所有键都是驼峰式大小写。
仅供参考 - “REST API 设计规则手册”于 2011 年 10 月发布。过去 8 年可能发生了变化。

【解决方案3】：

虽然我推荐使用连字符，我还要假设一个不在你列表中的答案：

什么都没有

我公司的 API 有 /quotationrequests/、/purchaseorders/ 等 URI。
尽管您说它是一个 Intranet 应用程序，但您将 SEO 列为一项优势。对于?q=foo+bar 的查询，Google 确实匹配了 URL 中的模式 /foobar/
我真的希望您不要像@ServAce85 所建议的那样，考虑对用户传入地址栏的任意字符串执行 PHP 调用！

【讨论】：

这个响应的坏处在于，从 SEO 的角度来看，机器无法理解一个词的结尾和另一个词的开头，因此这些信息丢失了。对于人类读者来说也很难。有一些单词级别的分隔符总比没有好。
@AlSweigart SEO 不相关，因为这是登录墙后面的 Intranet 应用程序。
我同意 @niel-mcguigan 的观点，即使这是一个 Intranet 应用程序，如果您在任何地方都使用连字符，那么需要记住的事情就更少了。
@DrewGoodwin 够了。虽然请注意我说的是“假设”而不是“推荐”:-) 而且域中通常没有连字符，所以在路径中使用它们已经是另外一件事要记住了。
它还会在 IDE 中引发各种拼写错误，因为无法检查混搭的单词。一个小小的挑剔可能但实际上拼错 REST 路由可能会导致错误，因此让拼写检查器工作实际上是一个不错的好处。

【解决方案4】：

简答：

以连字符作为分隔符的小写单词

长答案：

网址的用途是什么？

如果指向一个地址是答案，那么缩短的 URL 也能很好地工作。如果我们不让它易于阅读和维护，它就不会帮助开发人员和维护人员。它们代表服务器上的一个实体，因此必须按逻辑命名。

Google recommends using hyphens

考虑在您的网址中使用标点符号。 URL http://www.example.com/green-dress.html 比 http://www.example.com/greendress.html 对我们有用得多。我们建议您在 URL 中使用连字符 (-) 而不是下划线 (_)。

来自编程背景，camelCase 是命名联合词的流行选择。

但RFC 3986 将 URL 定义为对 URL 的不同部分区分大小写。由于 URL 区分大小写，因此保持低调（小写）始终是安全的，并且被认为是一个很好的标准。现在这把骆驼箱从窗户里拿出来了。

来源：https://metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

【讨论】：

【解决方案5】：

一般来说，它不会产生足够的影响来担心，特别是因为它是一个Intranet 应用程序，而不是一个通用的 Internet 应用程序。特别是，由于它是 intranet，所以 SEO 不是问题，因为您的 Intranet 不应该被搜索引擎访问。（如果是，它不是 Intranet 应用程序）。

任何值得一提的框架要么已经有一个默认的方法来做到这一点，要么很容易改变它处理多词 URL 组件的方式，所以我不会太担心。

也就是说，我是这样看待各种选项的：

连字符

连字符的最大危险是相同的字符（通常）也用于减法和数字否定（即减号或负号）。
连字符感觉在 URL 组件中很尴尬。它们似乎只在 URL 末尾用于分隔文章标题中的单词才有意义。或者，例如，为了 SEO 和用户清晰目的而添加到 URL 末尾的 Stack Overflow 问题的标题。

下划线

再一次，他们觉得 URL 组件有问题。它们打破了 URL 的流畅性（和美观/简洁性），因为它们本质上是在干净、流畅的 URL 中间添加了一个又大又重的明显空间。
它们倾向于与下划线融为一体。如果您希望您的用户将您的 URL 复制粘贴到 MS Word 或其他类似的文本编辑程序中，或者任何其他可能获取 URL 并使用下划线设置样式的地方（例如链接传统上是)，那么您可能希望避免使用下划线作为单词分隔符。特别是在打印时，带有下划线的带下划线的 URL 往往看起来像其中有空格而不是下划线。

驼峰式

到目前为止，我最喜欢它，因为它使 URL 看起来更流畅，并且没有前两个选项的任何错误。
对于难以区分大写和小写的人来说，可能稍微难以阅读，但这在 URL 中应该不是什么大问题，因为大多数“单词" 应该是 URL 组件，并由 / 分隔。如果您发现您有一个超过 2 个“单词”长度的 URL 组件，您可能应该尝试为该概念找到一个更好的名称。
确实可能存在区分大小写的问题，但大多数平台都可以调整为区分大小写或不区分大小写。任何它只是真正 2 种情况下的问题：a.) 人类输入 URL，b.) 程序员（因为我们不是人类）输入 URL。错字总是一个问题，无论是否区分大小写，所以这与所有一种情况没有什么不同。

【讨论】：

不同意。看看 SO，看看所有的 wordpress 网站，看看大多数新闻网站，它们都使用连字符。骆驼大小写也混合大小写，我认为网络应该全部小写。
在我看来，网络实际上应该不区分大小写。关于约定，如果您遵循 RoR (ruby on rails) 路线方法，您将使用下划线。通常，我这样做是为了在生成的路线和我的命名路线之间保持一致。尽管如此，我认为对我来说，破折号比下划线更好。
也许他们的 Intranet 中有一个内部搜索引擎？
不同意。你反对连字符的两个论点都是有缺陷的。否定或减法没有危险，因为我们在这里讨论的是元组的名称部分，您永远不应该为数学或否定计算或评估元组的名称部分。在 URI 中使用连字符也没有什么尴尬之处，因为它是缺乏成熟网站的长期最佳实践。它们也不需要按 Shift 键，几乎每个人都将它们视为单词边界。
在我的记忆中，连字符一直是 URL 中大量使用的规范，并且在当今的标准中绝对被认为是最佳实践。不使用它们是因为感觉尴尬对我来说似乎很尴尬。

【解决方案6】：

推荐使用spine-case（RFC3986强调），谷歌、PayPal等大公司都在使用。

来源：-https://blog.restcase.com/5-basic-rest-api-design-guidelines/

【讨论】：

无法在 RFC3986 中找到重点 - 您能指出在哪个部分吗？
确实，我也找不到。

【解决方案7】：

这是两全其美的。

我也“喜欢”下划线，除了你对他们的所有积极点外，他们还有一定的老派风格。

所以我要做的是使用下划线，并简单地在 Apache 的 .htaccess 文件中添加一个小的重写规则，以将所有下划线重写为连字符。

https://yoast.com/apache-rewrite-dash-underscore/

【讨论】：