在創建REST API時，API中是否有命名約定或實際標準（例如：URL端點路徑組件，查詢字符串參數）？駱駝帽是常態還是強調？其他？是否有任何有關REST API的命名約定準則？
例如：
api.service.com/helloWorld/userId/x
或
api.service.com/hello_world/user_id/x
注：這不是基於REST的API設計問題，而命名約定準則，以使用爲最終路徑組件和/或查詢使用字符串參數。
任何指導方針，將不勝感激。
我認爲你應該避免駱駝帽。規範是使用小寫字母。我還要避免下劃線和使用破折號，而不是
所以您的網址應該是這樣的（忽略你要求:-)設計問題）
api.service.com/hello-world/user-id/x
我不認爲駱駝的情況是在該示例中的問題，但我想在上面的例子更RESTful的命名規則是：
api.service.com/helloWorld/userId/x
而不是讓userId一個查詢參數（這是完全合法的）我的例子表示資源中，國際海事組織，一個更加RESTful的方式。
我想說，最好在REST URL中使用盡可能少的特殊字符。 REST的好處之一是它使服務的「界面」易於閱讀。駱駝案或帕斯卡案可能對資源名稱（用戶或用戶）很有用。我認爲REST並沒有真正的硬標準。
此外，我認爲甘道夫是正確的，它在REST中通常更清潔，不使用查詢字符串參數，而是創建定義您想要處理的資源的路徑。
仔細查看URI的普通網絡資源。那些是你的模板。考慮目錄樹;使用簡單的類似Linux的文件和目錄名稱。
HelloWorld不是一個很好的資源類。它似乎不是一個「事物」。它可能是，但它不是很像名詞般的。 A greeting是一件事情。
user-id可能是您正在提取的名詞。然而，可疑的是，您的請求的結果只是一個user_id。請求的結果更可能是用戶。因此，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/。
重點是提供資源之間的導航路徑。
我的問題更多地涉及最終路徑名和/或查詢字符串參數的命名約定，無論它們是什麼。我同意你的設計建議，所以謝謝你，但是這個問題我只是在問關於命名約定。 – jnorris 2009-04-22 18:02:03
號REST無關與URI命名約定。如果您將這些約定作爲API的一部分包含在帶外，而不是僅通過超文本，那麼您的API不是RESTful。
欲瞭解更多信息，請參閱http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
域名不區分大小寫，但URI的其餘部分可以肯定是。假設URI不區分大小寫是一個很大的錯誤。
Dropbox，Twitter，Google Web Services和Facebook的REST API全部使用下劃線。
'UserId'完全是錯誤的方法。動詞（HTTP方法）和名詞方法是Roy Fielding對The REST architecture的意思。名詞要麼是：
一個很好的命名約定：
[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，這是我們在產品中使用的。指南總是有爭議的......我認爲一致性有時比讓事情完美（如果有這樣的事情）更重要。
如果用的OAuth2驗證您的客戶我想你會需要強調的至少兩個的參數名：
我在使用駝峯我（尚未發佈）REST API。在編寫API文檔時，我一直在考慮將所有內容都更改爲snake_case，所以我不必解釋爲什麼Oauth參數是snake_case而其他參數不是snake_case。
這不是基於REST API的設計問題，而命名約定指引，使用使用的最終路徑部件和/或查詢字符串參數。在你的例子中，路徑組件應該像你使用的那樣是駱駝大帽，還是下劃線？ – jnorris 2009-04-22 17:01:39
既然在REST中你的URL是你的接口，那麼它就是一個API問題。雖然我不認爲你的例子有任何具體的指導方針，但我會親自去駱駝案例。 – Gandalf 2009-04-22 17:44:16
對於希望在HTTP堆棧的任何級別緩存的資源，您不應該使用查詢參數。 – aehlke 2009-07-21 14:34:46