REST APIを作成する場合、API内の命名規則に関するガイドラインやデファクトスタンダード（例：URLエンドポイントパスコンポーネント、クエリ文字列パラメーター）はありますか？キャメルキャップは標準またはアンダースコアですか？他？
例えば：
api.service.com/helloWorld/userId/x
または
api.service.com/hello_world/user_id/x
注：これはRESTful API設計の問題ではなく、使用される最終的なパスコンポーネントやクエリ文字列パラメーターに使用する命名規則のガイドラインです。
任意のガイドラインをいただければ幸いです。
回答:
キャメルキャップは避けるべきだと思います。通常は小文字を使用します。下線も避け、代わりにダッシュを使用します
したがって、URLは次のようになります（要求された設計の問題は無視されます:-)）。
api.service.com/hello-world/user-id/x
Dropbox、Twitter、Google Web Services、FacebookのREST APIはすべてアンダースコアを使用します。
通常のWebリソースの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/。
ポイントは、リソース間のナビゲーションパスを提供することです。
「UserId」は完全に間違ったアプローチです。動詞（HTTPメソッド）と名詞のアプローチは、Roy FieldingがRESTアーキテクチャに意味したものです。名詞は次のいずれかです。
良い命名規則の1つは次のとおりです。
[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はあまり友好的ではありません。
いいえ。RESTはURIの命名規則とは関係ありません。これらの規則をハイパーテキスト経由ではなく、アウトオブバンドでAPIの一部として含める場合、APIはRESTfulではありません。
詳細については、http：//roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-drivenを参照してください
ドメイン名では大文字と小文字が区別されませんが、URIの残りの部分では大文字と小文字が区別されます。URIで大文字と小文字が区別されないと想定することは大きな間違いです。
http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.htmlにガイドラインのリストがあり、製品で使用しています。ガイドラインは常に議論の余地があります...私は一貫性が物事を完璧にするよりも時には重要だと思います（そのようなものがある場合）。
その例ではラクダの問題が問題だとは思わないが、上の例のRESTfulな命名規則は次のようになると思います。
api.service.com/helloWorld/userId/x
むしろuserIdをクエリパラメータにする（これは完全に合法です）私の例では、IMOのリソースをよりRESTfulな方法で示しています。
Oauth2でクライアントを認証する場合、少なくとも2つのパラメーター名にアンダースコアが必要になると思います。
（まだ公開されていない）REST APIでcamelCaseを使用しました。APIドキュメントを書いている間、私はすべてをsnake_caseに変更することを考えていました。そのため、他のパラメーターではないのにOauthパラメーターがsnake_caseである理由を説明する必要はありません。
REST URLではできるだけ少ない特殊文字を使用することが望ましいと思います。RESTの利点の1つは、サービスの「インターフェース」を読みやすくすることです。キャメルケースまたはパスカルケースは、リソース名（ユーザーまたはユーザー）に適しています。RESTに関するハードスタンダードは本当にないと思います。
また、Gandalfは正しいと思います。通常、RESTではクエリ文字列パラメーターを使用せず、処理するリソースを定義するパスを作成する方がクリーンです。