我不认为骆驼的情况是这个例子中的问题，但我认为对于上面的例子，一个更RESTful的命名约定应该是:

api.service.com/helloWorld/userId/x

而不是让userId作为一个查询参数(这是完全合法的)，我的例子以一种更RESTful的方式表示该资源。

我认为在REST url中尽可能少地使用特殊字符是可取的。REST的好处之一是它使服务的“接口”易于阅读。Camel格式或Pascal格式可能适合于资源名称(Users或Users)。我不认为REST有什么严格的标准。

另外，我认为甘道夫是对的，在REST中不使用查询字符串参数通常更干净，而是创建定义你想要处理哪些资源的路径。

http://api.example.com/HelloWorld/Users/12345/Order/3/etc

仔细查看普通web资源的URI。这些就是你的模板。想想目录树;使用简单的类似linux的文件和目录名。

HelloWorld并不是一个很好的资源类。它看起来并不是一个“东西”。它可能是，但不太像名词。问候是一件事。

User-id可能是你取回的名词。然而，请求的结果仅仅是一个user_id是值得怀疑的。请求的结果更有可能是一个User。因此，user是你取回的名词

www.example.com/greeting/user/x/

对我来说很有道理。将重点放在使REST请求成为一种名词短语——通过层次结构(或分类法或目录)的路径上。尽可能使用最简单的名词，尽可能避免使用名词短语。

一般来说，复合名词短语通常表示层次结构中的另一个台阶。这里没有/hello-world/user/和/hello-universe/user/。你有/hello/world/user/和hello/universe/user/。或者可能是/world/hello/user/和/universe/hello/user/。

重点是提供资源之间的导航路径。

我觉得你应该避免戴驼峰帽。标准是使用小写字母。我还会避免使用下划线，而是使用破折号

所以你的URL应该是这样的(忽略你所要求的设计问题:-))

api.service.com/hello-world/user-id/x

不。REST与URI命名约定无关。如果您将这些约定作为API的一部分包含在带外，而不是通过超文本，那么您的API就不是RESTful的。

欲了解更多信息，请参见http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

域名不区分大小写，但URI的其余部分肯定可以。假设uri不区分大小写是一个很大的错误。

Dropbox、Twitter、谷歌Web Services和Facebook的REST API都使用下划线。

“UserId”是完全错误的方法。动词(HTTP方法)和名词方法是Roy Fielding对REST架构的定义。名词可以是:

一堆东西 一件事

一个好的命名约定是:

[POST or Create](To the *collection*)
sub.domain.tld/class_name.{media_type} 

[GET or Read](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[PUT or Update](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[DELETE](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[GET or Search](of a *collection*, FRIENDLY URL)
sub.domain.tld/class_name.{media_type}/{var}/{value}/{more-var-value-pairs}

[GET or Search](of a *collection*, Normal URL)
sub.domain.tld/class_name.{media_type}?var=value&more-var-value-pairs

其中{media_type}是json, xml, rss, pdf, png，甚至html之一。

可以通过在末尾添加's'来区分集合，例如:

'users.json' *collection of things*
'user/id_value.json' *single thing*

但这意味着你必须记录你在哪里写了“s”，在哪里没有写。加上半个地球(首先是亚洲人) 说的语言没有明确的复数，所以URL对他们不太友好。

我在http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html上有一份我们在prod中使用的指南清单。指南总是有争议的…我认为一致性有时比把事情做到完美更重要(如果有的话)。

如果你使用Oauth2对客户端进行身份验证，我认为你至少需要在两个参数名上加下划线:

client_id client_secret

我在我的REST API(尚未发布)中使用了camelCase。在编写API文档时，我一直在考虑将所有内容都更改为snake_case，这样我就不必解释为什么Oauth参数是snake_case，而其他参数不是。

参见:https://www.rfc-editor.org/rfc/rfc6749