web-dev-qa-db-ja.com

WebサイトのわかりやすいURLとデータベースIDの現実の比較

製品、ブログ投稿など、リソースのデータベースがあります。公開ウェブサイトのために、それらに対処するためのURLスキームを設計する必要があります。

データベースIDがバインドされている2つの例を次に示します。

これはフレンドリーな例です：

（そこでの私のブラウジング生活を少し垣間見る）

メールやドキュメントでホバーしたり表示したりしたときに、URLの最後に何があるかがわかるので、わかりやすいURLが好きです。それはSEOにとってより良い、または以前はそうでした。

ドキュメントまたは製品の名前を変更するとどうなりますか？変更されたため（Wikiは変更されない可能性がありますが、リソースは変更される可能性があります）、タイプミスが原因です。私たちのリソースは非常に技術的で、長い言葉と間違いがちです。

また、数値であるデータベースIDがあります。ふりのレンタル店を使用してビデオのアドレスのアイデアを見てみましょう：

IDは明白であり、DBルックアップで使用されます。いいね.

スライディングドアビットは一意ではなく、ビデオタイトルから生成されただけなので、GETで検証できます。そのため、グライドドアが入力され、ドキュメント287171に実際にあるものと一致しない場合、404が応答します。

あるいは、それが無視され、誰かが気にかけていたとしても、人間が好きなものをそこに貼り付けることができます。したがって、このURLも機能します。

わかりやすい部分の確認に関する問題は、前述のように、名前の変更またはタイプミスの修正の問題です。名前が変更された場合、ドメイン内でそのようなことが起こっても、そこにあるURLを壊したくないので、次のようにします。

  • フレンドリーな部分を確認しないでください。

  • 確認しますが、以前のフレンドリIDが引き続き機能するように、フレンドリパーツの「履歴」をデータベースレコードに追加します。

あなたの考えやアイデアは大歓迎です。

ルーク

web-applicationsrestwebwebsiteshttp
24
Luke Puplett

URLにIDを保持することは、最も将来の証明方法であり、実証したように、URLは比較的見栄えがよくなる可能性があります。

複数のプロジェクトで使用される別のオプションは、以前に使用されたスラグの履歴を保持することです。タイトルが変更されたら、スラッグを更新し、誰かが古いスラッグを探した場合は、古いスラッグのリストを検索します。そうすれば、古いスラッグを新しいコンテンツに再利用できます（または実装に依存しません）。

Wordpressはそれを行い、そして friendly_id gem もそうしました。これはおそらくRailsのフレンドリーIDを管理するために最も使用されるgemです。

また、見栄えの良いURLが好きですが、これはおそらく技術に詳しいユーザーが使用する機能である可能性が高いことを覚えておくことは重要です。一部のブラウザーは、URL（またはその一部）を非表示にし始めています。

7
mbillard

私は過去に2つの異なるシナリオを使用しました。

  1. /id/some-slugここでidはルックアップに使用されます、スラッグは使用されません。したがって、スラッグは何でもかまいません。ただし、スラッグが実際のスラッグと一致しない場合、ユーザーは現在のバージョンにリダイレクトされます。

  2. /permalinkURLにIDが必要ない場合またはURLが変更されない場合使用可能なIDがあります（ [1] および [2] を参照）。もちろん、この場合permalinkがルックアップに使用されます。現在のスラッグとパーマリンク（最初のスラッグ）の両方がデータベースに格納されます。

これらのどちらの方法でも、データベースにスラッグの履歴を保持する必要がありますが、すぐに問題が発生します。

ps：2番目のケースでは、ソーシャルクレジットを維持するために非常に具体的なルーティングが必要になります。

  • 必要に応じて、ユーザーを現在の（非パーマリンク）URLにリダイレクトします
  • パーマリンクをソーシャルボタンのURLとして使用する
  • 常にFacebookクローラーをパーマリンクにリダイレクトする

[1] および [2] を再度参照してください。

3
Lode

ドキュメントまたは製品の名前を変更するとどうなりますか？

HTTP応答301（移動済み）はこの目的のために設計されました。クライアントが古いURIにアクセスする場合は、新しいURIを送信するだけで、そのURIにリダイレクトできます。

スライディングドアビットは一意ではなく、ビデオタイトルから生成されただけなので、GETで検証できます。そのため、グライドドアが入力され、ドキュメント287171に実際にあるものと一致しない場合、404が応答します。

私が正しく従うと、これは重複する作業です。同じURIにリソースの名前識別子とIDの両方があります。それは何の目的も果たしません。

同じ名前の複数の映画が心配な場合は、映画に関する追加情報をURLに追加できます。

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

または

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

それがあなたのデータモデルにとって理にかなっているならば、特にあなたがグループ化している唯一のものがビデオであることであるならば、IDの使用には何の問題もないと言っていました。

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

クライアントは、コンピューターでも人間のユーザーでも、そもそもURI構造に過度に依存するべきではありません。クライアントは、返されたコンテンツを調べて、どのリソースを見つけるべきかを理解する必要があります。

誰かがリソースの場所を推測したり、共有プロパティ（つまり、2004年のすべての映画）に基づいて構造を上下に移動したりするのを簡単にする賢明なURIシステムがあることには何の問題もありませんが、システムは依存すべきではありません。その上で、URIを変更してもクライアントは壊れません。

または別の言い方をすれば、

http://vidsyeah.com/video/studios/paramount/sliding_doors

に

http://vidsyeah.com/video/12323

クライアントはURLではなくコンテンツを参照する必要があるため、クライアントが壊れることはありません。

2
Cormac Mulhall

BBCは次のスラグを使用します。

  • 英数字（コンパクト化のため）
  • 一意（ルックアップ用）
  • 非順次（データベースに追加された順序が公開されないようにするため）

例えば http://www.bbc.co.uk/programmes/b006mk7h

各公開プログラムには、IDとスラッグの両方があります。これで、IDは通常どおり自動インクリメント整数になり、ギャップは公開されません。

1
Nicholas Shanks

RESTfulな観点から見ると、URIは使いやすさを向上させるために、予測可能で一貫した階層構造に従う必要があります。

これにより、消費者が使いやすくなります。データに関係がある場合、何らかの階層が必要になります。

スキームは次のようです：\video\[name]\[id]

この名前が今後の分類に使用されない場合は、\video\[id].を優先して削除することができます。

ただし、ビデオを分類する場合は、名前が役立つ場合があります。

例：

  • \ video\SwingingDoors\123
  • \ video\SwingingDoors\124
  • \ video\SlidingDoors\125
  • \ video\SlidingDoors\126

これは、アクセスをモデル化する方法に関する設計上の決定です。

0
Jon Raynor