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


24

製品、ブログ投稿など、リソースのデータベースがあります。パブリックWebサイト用に、それらに対処するURLスキームを設計する必要があります。

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

わかりやすい例は次のとおりです。

(そこでのブラウジング生活を少し垣間見ます)

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

ドキュメントまたは製品の名前が変更されるとどうなりますか?変更された(Wikiは変更されないかもしれませんが、リソースは変更される可能性があります)か、タイプミスのためですか?私たちのリソースは非常に技術的で、長い言葉であり、間違いを起こしやすいものです。

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

IDは明らかであり、DBルックアップで使用されます。いいよ

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

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

友好的な部分を検証する際の問題は、前述のように、名前の変更またはタイプミスの修正の問題です。名前が変更され、ドメイン内で実際に発生した場合、そこにあるURLを壊したくないので、次のようにします。

  • 友好的な部分を確認しないでください。

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

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

ルカ


11
このサイトでも、組み合わせを使用していますhttp://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(タイトルの変更を考慮して未検証バージョンを使用し、短い「共有」リンクも単なるIDです:(http://programmers.stackexchange.com/q/255684/25768およびバッジトラッキングのユーザーID)
ラチェットフリーク

11
URLに一意のIDがある場合、スラッグ部分を検証する理由がまったくわかりません。ルックに使用し、ルックアップには無視します。
トールステンミュラー14

どちらかが適切な回答をしたい場合は、投票して、ポイントを獲得します。数日以内に投票を行い、最も投票された人への回答を授与します。
ルークプレット14


3
スラッグという言葉を前に知らなかった 岩の下にいたに違いない。ゲディット?
ルークププレ14

回答:


6

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

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

Wordpressのは、それをしたし、そのようにしたfriendly_id宝石おそらくRailsのための友好のIDを管理するための最も使用される逸品です。

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


2
このスラッグの歴史は私が考えていたものです。質問を投稿してから、チェックされていないスラッグを持つ多くの大きな名前付きサイトに気づきました。何でも言うように変更できます。amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8は動作します。StackExchangeは、正しいリンクが表示および共有されるようにブラウザを「修正」およびリダイレクトするため、賢明です。
ルークププレット14

「スラッグ」は人々にとってはあまり有用ではなく、検索エンジン最適化にとってはより有用です。「スラッグ」または「フレンドリーURL」にはページのコンテンツに関連するキーワードが必要だからです。上級ユーザーは、サイトにわかりやすいURLを含める理由ではありません。検索エンジンのランキングが主な理由である傾向があります。
グレッグブルクハート14

同意しません。IDだけのURLは扱いにくいです。それらのリストから、どの1つに戻りたいかを覚えるのは困難です。または、リンクのもう一方の端に何か不適切なものがあるかどうか。Chromeのアドレスバーは、URLの任意の部分でも提案するため、便利です。
ルークププレ14

1
@LukePuplettはい、私はSEのURLの扱い方がナメクジになると最も簡単だと思います。
mbillard 14

唯一の違いは、クリック率である@GregBurghardt、ユーザーフレンドリーなURLに少しクリックする傾向がある:stackoverflow.com/questions/505793/...
mbillard

3

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

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

  2. /permalink例のために私たちはURLのidたくなかった、またはどこのURLは変更しないでくださいをもかかわらず、 ID利用可能である(参照[1][2] )。もちろん、この場合permalinkはlookupに使用されます。現在のスラッグとパーマリンク(最初のスラッグ)の両方がデータベースに保存されます。

これらのどちらの方法でも、データベースにナメクジの履歴を保持する必要はありませんが、すぐに問題が発生します。


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

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

[1][2]をもう一度参照してください。


なぜ問題になるのでしょうか?私が保持し、IDとスラッグが何かである場合、訪問者は実際のページに移動します。SEOにとって有害で​​すか?
ジュナナランジャン

ナメクジの歴史を保持するということですか?誰かがそのようなナメクジを再利用したいときはどうしますか?同じまたは別のIDですか?複数のリダイレクトを防ぐために、データベースやコードをどのように設計しますか?削除後に存在を非表示にし、以前の存在を公開するリダイレクトが必要ですか?これはすべて不可能ではありませんが、あらゆる種類の質問を提起しますが、私は単に設計によって防止しています。
ロード

私が言いたかったのは、URLにIDが存在する場合、スラッグが何であれ、要求されたページにリダイレクトされるということです。その後、ナメクジの歴史は関係ありません。しかし、アンドロイドにとっては問題があることに同意します。
ジュナナランジャン

1
あ、そう。それが正しいシナリオ1を追加したものですか?それとも別の意味ですか?
ロード

はい。それは正しいです。
ジュナナランジャン

2

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

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

スライドドアビットは一意ではなく、ビデオタイトルから生成されただけで、GETで検証できます。したがって、スライドドアが入力され、doc 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ではなくコンテンツを参照する必要があるため、クライアントは中断しないでください。


ジョンの答えのように、これについて考えるとき、あなたはUXの帽子をかぶっていないと思います。アドレスの有用性を高めたい。質問のコメントを参照してください:「メールまたはドキュメントでホバーまたはURLを参照すると、URLの末尾に何があるかを知っているので、わかりやすいURLが好きです。SEOに適しています。
ルークピュレット14

2
301をスローするには、正しいリソースを検索できる必要があるため、履歴が必要です。
ルークププレ14

1
履歴が必要ですが、リソースが変化するサイトがある場合は、とにかく良い考えです。
コーマックマルホール14

フレンドリーなURIに問題はありません。URIが何でも構いませんが、最後にIDがあれば機能します。それは実際には問題を解決せず(ユーザーはまだIDを覚える必要があります)、混乱するURIスキームを導入します(ユーザーは、スペルミスのある2つの異なるURIが同じリソースに行く理由を合法的に尋ねるかもしれません)
Cormac Mulhall

1
URIのスペルミスを心配している場合、これに対処する一般的な方法は、誤ってスペルされたURLの404エラーページでURIを提案することです。単語パターン検索を実行して、ユーザーが探していると思われるものを返すことができます。
コーマックマルホール14

1

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

  • 英数字(コンパクト化のため)
  • 一意(検索用)
  • ノンシーケンシャル(したがって、dbに追加される順序は公開されません)

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

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


0

RESTfulの観点からは、URIは予測可能かつ順応性のある階層構造に従って、ユーザビリティを強化する必要があります。

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

スキームは次のように見えます: \video\[name]\[id]

名前がそれ以上の分類に使用されていない場合は、削除することができます \video\[id].

ただし、ビデオを分類したい場合は、名前が役に立つかもしれません。

例:

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

アクセスがどのようにモデル化されるかについての設計上の決定です。


API /サイト情報アーキテクチャPoVからこれについて考えていると思います。私は、人間とSEOを支援するために、生成されたわかりやすいURLパーツを紹介しようとしていました。どうやらこれは一般的なことであり、「スラッグ」の名前で行く。この名前は分類に使用されておらず、URLとサイト/ブランドでより良いUXを作成するために追加されます(ドロップされません)。
ルークプレット14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.