我正在为一个内部网络应用程序设计一个基于http的API。我意识到这是一个非常小的问题，但是:我应该使用连字符、下划线或骆驼号来分隔uri中的单词吗?
以下是我最初的想法:
camelCase
如果服务器不区分大小写，可能会出现问题 似乎在查询字符串键(http://api.example.com?**searchQuery**=…)中有相当广泛的使用，但在其他URI部分中没有
连字符
比其他选择更具美感 似乎在URI的路径部分被广泛使用 从来没有见过连字符的查询字符串键在野外 可能对搜索引擎优化更好(这可能是一个神话)
下划线
编程语言可能更容易处理 一些流行的api (Facebook, Netflix, StackExchange等)在URI的所有部分都使用下划线。
我倾向于用下划线表示所有内容。事实上，大多数大公司都在使用它们(见https://stackoverflow.com/a/608458/360570)。
当前回答
简短的回答:
用连字符作为分隔符的小写单词
长一点的回答:
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
其他回答
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也是
这是两全其美的东西。
我还“喜欢”强调，除了你对他们的所有积极的观点外，他们也有某种老派的风格。
因此，我所做的就是使用下划线，并简单地在Apache的.htaccess文件中添加一个小重写规则，将所有下划线重写为连字符。
https://yoast.com/apache-rewrite-dash-underscore/
建议使用脊壳(突出显示为 RFC3986)，这个案例被谷歌，PayPal，和其他大 公司。
来源:https://blog.restcase.com/5-basic-rest-api-design-guidelines/
编辑:虽然RFC上的重点没有找到，但关于脊柱病例的建议仍然有效(正如已经在其他答案中指出的那样)
一般来说，它不会有足够的影响来担心，特别是因为它是一个内部网应用程序，而不是一个通用的互联网应用程序。特别是，因为它是内部网，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.
你应该在可爬行的web应用程序URL中使用连字符。为什么?因为连字符分隔单词(以便搜索引擎可以索引单个单词)，而且连字符不是单词字符。下划线是一个单词字符，这意味着它应该被认为是单词的一部分。
在Chrome中双击这个:camelCase 在Chrome中双击这个:under_score 在Chrome中双击该文件:连字符
看看Chrome(我听说谷歌也做了一个搜索引擎)只认为其中一个是两个词?
camelCase和underscore也要求用户使用shift键，而hyphenated则不需要。
所以，如果你应该在一个可爬行的web应用程序中使用连字符，为什么要在一个内部网应用程序中做一些不同的事情呢?少记一件事。
