URLでタイトルの大文字を使用する必要がありますか?


9

現在、複数のWebアプリケーションを使用するサイト全体で一貫した命名規則を決定しています。歴史的に、私は「小文字のすべての文字!」を提唱してきました。URLを作成する場合:

http://example.com/mysystem/account/view/1551

ただし、1年か2年以内に、具体的にはASP.NET MVCを使い始めて、RESTベースのURLとの取引が増えたため、URL内の各セクション/単語の最初の文字を大文字にするのが好きになりました読みやすい(imho)。

http://example.com/MySystem/Account/View/1551

私たちは人々 URLを読んだり理解したりする必要がある状況にないので、それ自体はドライバーではありません。私たちが求めている主なものは、合理的で理にかなった一貫したアプローチです。

何らかの方法で良いことを宣言する標準、または別のものよりも優先を選択する(少なくとも現実的には現代的な)セットアップで遭遇する可能性のある問題はありますか?現在、この議論の一般的なコンセンサスは何ですか?

回答:


10

選択は主に表面的なものであるため(つまり、ほとんどのシステムは大文字と小文字を区別せず、ユーザーは確かに区別しません)、そのため、満足できる方だけを使用することをお勧めします。アプリケーション内の一貫性が重要であり、選択した方法ではありません。

ASP.Netを使用している場合は、PascalCaseアプローチを使用することをお勧めします。これは、Microsoftフレームワーク(システムライブラリなど)内に存在する傾向があるためですが、一貫性以外に「ベストプラクティス」はありません。

ほとんどのブラウザは、ユーザーからURLを隠すというかなり良い仕事をしており、ホームページとしてGoogleを持っている非常に多くの人々がFacebookを検索してクリックします-FacebookのURLを入力するのではなくブラウザ。


7
しかし、システム 差別化します…
ghoppe 2012

1
大文字と小文字の区別はサーバー構成に依存するため、システムで大文字と小文字が区別されないことを誤って述べるのではなく、検討する価値があることを少なくとも言及する必要があります。
jleach

@ jdl134679完了。
TZHX 2016

4

内部のWebサイトについては、一貫性があればそれほど重要ではありません。

外部の一般向けのサイトの場合、おそらくLinux / Apache Webホスティングの標準である小文字に固執する必要があります。記憶しているように、Firefoxの一部のバージョンでは、IEとは異なる方法でURLの大文字と小文字を処理するようです。これはChromeにも適用される場合があります。

一貫した大文字小文字の区別は、検索エンジン最適化にとっても重要です。Googleがlower-case.aspxとLower-Case.aspxを重複するコンテンツを含む別のページとして表示しないようにする必要があります。彼らのアルゴリズムはこの誤ったアイデンティティを防止しようとしますが、それは時々起こり、ページにペナルティを課す可能性があります。


2

ユーザーが好きなように入力できる限り、それは本当に重要ではありません。個人的には好きですがTitleCase、反対する人も多いです。あなたが首尾一貫しているなら、誰も気にしないでしょう。

Webサーバーが何らかの理由でhttp://foo.com/HelloWorldにアクセスしようとしたときに表示されない場合はhttp://foo.com/helloworld、すべて小文字にする必要があります。最近では完全なURLを入力することはめったにありませんが、大文字をいじる必要なく前面のアドレスにアクセスできる必要があります。


2

MVCの使用を開始したことが、RESTの抽象化に「リーク」しないようにする必要があります。単語間にダッシュを含むすべての小文字のURLを使用するのには十分な理由があります。URI(ドメイン名ではない)では大文字と小文字が区別されます。すべてを小文字にし、ダッシュを使用して単語を区切ると、多くの推測作業と1回限りの処理がなくなり、プロキシサーバー(nginx、nodejs、apache ...)を使用すると、すべてが壊れ始めるわけではありません。突然大文字と小文字が区別されるためです。

「MiXeD-CaSe NaMeS。大文字と小文字と小文字を組み合わせたURLでユーザーを混乱させないでください。小文字に固執し、推測させないでください。ユーザーは実際に大文字と小文字を混在させてURLを入力し、サーバー上でそれを正規化して、適切な大文字小文字を処理します。」


1

TLDは、大文字と小文字が区別されず、Windowsのパスは、資本とパスカルケースの組み合わせを使用しながら、我々のアプリケーションは、パス、または成分は、その中に、通常、標準的なケースに正規化された着信要求パス、に敏感であるので/format/JSON/及び/format/json/2の要求であります異なる形式で、2つの異なるリソースを参照します。

http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/を見たときはいつでも、開発者の意図は主に他のものと少し異なるように見えることだと感じましたが、それは何でもありません革新的であり、どちらも読みやすさを向上させるのに役立ちません。特に、分析のために競合する他の文字であるIlO0があるためです。

URLの特定の部分だけを大文字にするなどの単純なものは読みやすさにプラスの影響を与える可能性があり、誰かがすでにどこかですでに近づいていると確信しているので、私はコンセンサスに気づいていません。 URLにレターケースを適用することに関しては、興味深いアイデアがあります。

しかし、ほとんどのWebサーバーはLinuxで実行されており、入力では大文字と小文字が区別されるため、開発者は常に着信テキストデータを標準化することになるため、私はそれがどのように行われているかに固執しています。


0

NEVERユーザビリティの理由でタイトルケースを使用していません!あなたの携帯電話で異なるケースのURLを実行するために費やす時間とクリックの時間を想像してみてください!


私のiPhoneでは、タイトルケースに必要な追加のキーストロークは「-」または「_」よりも少なくなっています。
BradS 2013

最新のスマートフォン、少なくともWindowsフォンでは、
Caps
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.