一般来说，它不会有足够的影响来担心，特别是因为它是一个内部网应用程序，而不是一个通用的互联网应用程序。特别是，因为它是内部网，SEO不是一个问题，因为你的内部网不应该被搜索引擎访问。(如果是，也不是内部网应用)。

任何值得信赖的框架要么已经有默认的方式来做这件事，要么很容易改变它处理多字URL组件的方式，所以我不会太担心这个问题。

也就是说，以下是我对各种选择的看法:

连字符

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

下划线

Again, they feel wrong in URL components. They break up the flow (and beauty/simplicity) of a URL, since they essentially add a big, heavy apparent space in the middle of a clean, flowing URL. They tend to blend in with underlines. If you expect your users to copy-paste your URLs into MS Word or other similar text-editing programs, or anywhere else that might pick up on a URL and style it with an underline (like links traditionally are), then you might want to avoid underscores as word separators. Particularly when printed, an underlined URL with underscores tends to look like it has spaces in it instead of underscores.

CamelCase

By far my favorite, since it makes the URLs seem to flow better and doesn't have any of the faults that the previous two options do. Can be slightly harder to read for people that have a hard time differentiating upper-case from lower-case, but this shouldn't be much of an issue in a URL, because most "words" should be URL components and separated by a / anyways. If you find that you have a URL component that is more than 2 "words" long, you should probably try to find a better name for that concept. It does have a possible issue with case sensitivity, but most platforms can be adjusted to be either case-sensitive or case-insensitive. Any it's only really an issue for 2 cases: a.) humans typing the URL in, and b.) Programmers (since we are not human) typing the URL in. Typos are always a problem, regardless of case sensitivity, so this is no different that all one case.

虽然我推荐连字符，但我也会假设一个不在你列表上的答案:

什么都没有

我公司的API有类似/quotationrequests/， /purchaseorders/等uri。 尽管你说这是一个内部网应用，但你把搜索引擎优化列为一个好处。谷歌在查询?q=foo+bar时匹配URL中的/foobar/模式 我真的希望您不要考虑像@ServAce85所建议的那样，对用户传递到地址栏的任意字符串执行PHP调用!

REST api的标准最佳实践是使用连字符，而不是骆驼字或下划线。

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

另外，请注意Stack Overflow本身在URL中使用连字符:…/连字符下划线-or-camelcase-as-word- delimator - In -uri

http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually也是

你应该在可爬行的web应用程序URL中使用连字符。为什么?因为连字符分隔单词(以便搜索引擎可以索引单个单词)，而且连字符不是单词字符。下划线是一个单词字符，这意味着它应该被认为是单词的一部分。

在Chrome中双击这个:camelCase 在Chrome中双击这个:under_score 在Chrome中双击该文件:连字符

看看Chrome(我听说谷歌也做了一个搜索引擎)只认为其中一个是两个词?

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

所以，如果你应该在一个可爬行的web应用程序中使用连字符，为什么要在一个内部网应用程序中做一些不同的事情呢?少记一件事。

这是两全其美的东西。

我还“喜欢”强调，除了你对他们的所有积极的观点外，他们也有某种老派的风格。

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

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

简短的回答:

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

长一点的回答:

URL的目的是什么?

如果指向一个地址是答案，那么一个缩短的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

建议使用脊壳(突出显示为 RFC3986)，这个案例被谷歌，PayPal，和其他大 公司。

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

编辑:虽然RFC上的重点没有找到，但关于脊柱病例的建议仍然有效(正如已经在其他答案中指出的那样)

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