URIの単語区切り文字としてのハイフン、アンダースコア、またはキャメルケース？

イントラネットアプリ用にHTTPベースのAPIを設計しています。私はそれが物事の大まかな体系ではかなり小さな懸念事項であることを理解していますが、URI内の単語を区切るためにハイフン、アンダースコア、またはキャメルケースを使用する必要がありますか？

これが私の最初の考えです。

キャメルケース

• サーバーで大文字と小文字が区別されない場合に考えられる問題
• クエリ文字列のキーにかなり広範囲に使用しているようだ（http://api.example.com？SEARCHQUERY = ...）ではなく、他のURIの部分で

ハイフン

• 他の選択肢よりも審美的に楽しい
• URIのパス部分で広く使用されているようです
• 実際にハイフネーションされたクエリ文字列キーを見たことがない
• おそらく SEOに適しています（これは神話かもしれません）

下線

• プログラミング言語が扱いやすい可能性
• いくつかの人気のあるAPI（Facebook、Netflix、StackExchangeなど）は、URIのすべての部分でアンダースコアを使用しています。

私はすべてのアンダースコアに傾いています。大企業のほとんどがそれらを使用しているという事実は説得力があります（https://stackoverflow.com/a/608458/360570を参照）。

クロール可能なWebアプリケーションのURLではハイフンを使用する必要があります。どうして？ハイフンは単語を分離し（検索エンジンが個々の単語にインデックスを付けることができるようにするため）、単語の文字ではありません。アンダースコアは単語の文字です。つまり、単語の一部と見なされます。

これをChromeで
ダブルクリック：camelCaseこれをChromeでダブルクリック：under_scoreこれをChromeで
ダブルクリック：ハイフン付き

Chrome（Googleも検索エンジンを作っているそうです）が、そのうちの1つだけが2つの単語であると考えているのを見てください。

camelCaseそしてunderscoreまた、使用することをユーザに要求shiftに対し、鍵をhyphenatedしません。

では、クロール可能なWebアプリケーションでハイフンを使用する必要がある場合、イントラネットアプリケーションで別のことをする必要があるのはなぜですか。覚えておくべきことが1つ少なくなります。

REST APIの標準的なベストプラクティスは、キャメルケースやアンダースコアではなくハイフンを使用することです。

これは、OreillyのMark Masseの "REST API Design Rulebook"によるものです。

さらに、Stack Overflow自体がURLでハイフンを使用していることに注意してください。 .../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

WordPressと同様：http : //inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually

一方で、私はハイフンをお勧めします、私はまた、あなたのリストにない答えを仮定しなければなりません。

何もない

• 私の会社のAPIのようなURIを持っている/quotationrequests/、/purchaseorders/などを。
• イントラネットアプリだとおっしゃっていましたが、SEOをメリットとして挙げていました。Googleは、クエリのURLのパターン/ foobar /に一致します?q=foo+bar
• @ ServAce85が示唆するように、ユーザーがアドレスバーに渡す任意の文字列に対してPHP呼び出しを実行することを考慮しないことを本当に望みます。

一般的に、イントラネットアプリであり、汎用のインターネットアプリではないため、心配するほどの影響はありません。特に、イントラネットであるため、検索エンジンがイントラネットにアクセスできないようにする必要があるため、SEOは問題になりません。（もしそうなら、それはイントラネットアプリではありません）。

そして、ソルトの価値があるフレームワークには、これを行うデフォルトの方法がすでにあるか、マルチワードのURLコンポーネントの処理方法を変更するのがかなり簡単なので、あまり心配する必要はありません。

とはいえ、さまざまなオプションの表示方法は次のとおりです。

ハイフン

• ハイフンの最大の危険は、同じ文字が（通常）減算と数値否定（つまり、マイナスまたはマイナス）にも使用されることです。
• ハイフンはURLコンポーネントで扱いにくいと感じます。記事のタイトルで単語を区切るために、URLの最後でのみ意味をなすようです。または、たとえば、SEOとユーザーの明確化のためにURLの末尾に追加されるStack Overflow質問のタイトル。

下線

• 繰り返しになりますが、URLコンポーネントには誤りを感じます。それらは本質的にクリーンで流れるURLの真ん中に大きくて見かけ上のスペースを追加するため、URLのフロー（および美しさ/シンプルさ）を分割します。
• 下線と混ざりがちです。ユーザーがURLをMS Wordまたは他の同様のテキスト編集プログラム、またはURLを取得して下線でスタイル設定できる他の場所（従来のリンクと同様）にコピーアンドペーストすることを期待している場合は、単語の区切り文字としてアンダースコアを使用しないでください。特に、印刷すると、下線付きの下線付きURLは、下線ではなくスペースが含まれているように見えます。

キャメルケース

• URLの流れが良くなり、前の2つのオプションのような欠点がないため、私のお気に入りです。
• することができ、わずかに小文字から大文字を区別する苦労を持っている人々のために読み取ることが難しく、ほとんどの「言葉」はURLの構成要素とすることとで区切らなければならないので、これは、URLに多くの問題をすべきではない/とにかく。2語を超えるURLコンポーネントがあることがわかった場合は、その概念に適した名前を見つけてください。
• それはありません大文字と小文字を区別して可能性の問題がありますが、ほとんどのプラットフォームでは大文字と小文字の区別の有無のいずれかになるように調整することができます。これは、実際には2つの場合にのみ問題になります。a。）人間がURLを入力する場合、およびb。）プログラマー（人間ではないため）がURLを入力する場合。大文字と小文字の区別に関係なく、入力ミスは常に問題なので、これはすべて1つのケースと違いはありません。

簡潔な答え：

ハイフンをセパレーターとする小文字の単語

長い答え：

URLの目的は何ですか？

アドレスを指すことが答えである場合、短縮URLも適切に機能します。読みやすく、保守しやすくしないと、開発者と保守者の両方に役立ちません。これらはサーバー上のエンティティを表すため、論理的に名前を付ける必要があります。

ハイフンの使用をお勧めします

URLで句読点を使用することを検討してください。URL http://www.example.com/green-dress.htmlは、http://www.example.com/greendress.htmlよりもはるかに便利です。URLには、アンダースコア（_）ではなくハイフン（-）を使用することをお勧めします。

プログラミングの背景から来たキャメルケースは、共同語に名前を付けるための人気のある選択肢です。

しかし、RFC 3986は、URLをURLのさまざまな部分で大文字と小文字を区別するものとして定義しています。URLは大文字と小文字を区別するため、キーを低くする（小文字にする）ことは常に安全であり、優れた標準と見なされています。これで、キャメルケースが窓から出てきます。

ソース：https : //metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

ここに両方の​​長所があります。

私はまた、アンダースコアを「好き」にしています。それらについてのあなたのすべての肯定的な点に加えて、彼らには特定の古いスタイルもあります。

下線を使用し、Apacheの.htaccessファイルに小さな書き換えルールを追加して、すべての下線をハイフンに書き換えます。

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