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

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

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

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

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

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

---

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

---

虽然我建议使用连字符，但我还将假设一个不在您列表中的答案：

什么都没有

我公司的 API 有 /quotationrequests/、/purchaseorders/ 等 URI。

尽管您说它是一个 Intranet 应用程序，但您将 SEO 列为一项优势。对于 ?q=foo+bar 的查询，Google 确实匹配 URL 中的模式 /foobar/

我真的希望您不要像@ServAce85 建议的那样考虑对用户传递到地址栏的任意字符串执行 PHP 调用！

---

简短的回答：

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

长答案：

URL 的目的是什么？

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

Google recommends using hyphens

考虑在 URL 中使用标点符号。 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

---

一般来说，它不会产生足够的影响，特别是因为它是一个 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。拼写错误总是一个问题，无论区分大小写，所以这是没有什么不同，所有一个案例。

---

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

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

编辑：虽然 RFC 上的亮点无处可寻，但关于脊柱病例的建议仍然有效（正如其他答案中已经指出的那样）

---

我们应该在网页 URL 中使用连字符来说服搜索引擎分别索引 URL 中的每个关键字。

---

这是两全其美的。

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

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

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

---