フレンドリーな URL スキーム?

StackOverflow https://stackoverflow.com/questions/112695

  •  02-07-2019
  •  | 
  •  

質問

私に欠けている多くのもののうちの 1 つは、 スクレーパーサービス 先週設定した URL はとても素敵です。現在、ユーザーパラメータはスクリプトに渡されています ?u=, 、これは怠惰なハック (スクリプトが明らかにそうなっている) の症状です。ただし、やり直すことを検討しており、利用可能なオプションについてフィードバックが欲しいと思っています。現在、ユーザーに情報を提供するページは更新とチャートの 2 つです。私が思いついた2つの可能性を紹介します。「1234」はユーザーID番号です。技術的な理由により、残念ながらユーザー名は使用できません。

  • http://< tld >/update/1234
  • http://< tld >/chart/1234

または

  • http://< tld >/1234/update
  • http://< tld >/1234/chart

オプション #1 は、概念的には、ユーザー ID を使用して update を呼び出します。オプション #2 は、ユーザー ID を操作する動詞を提供することです。

一貫性の観点からすると、どちらがより理にかなっていますか?

もう一つ言及されているオプションは、

  • http://< tld >/user/1234/update
  • http://< tld >/user/1234/chart

これにより、特定のユーザーに関係のないページ用のスペースが提供されます。つまり

  • http://< tld >/stats
役に立ちましたか？

解決

ディレクトリ構造 (に存在するもの) はユーザーのデータに対する 2 つの異なる機能であるため、私は userid -- オプション #2 -- を使用するほうが穏やかです。それはユーザーのグラフであり、ユーザーの更新です。

ただし、これはかなり些細な点であり、この機能の大幅な拡張計画があるかどうかは不明です。

  • 今後はすべて、個々のユーザー向けの追加機能 foo、bar、baz になるのでしょうか?そうであれば、上記の理由により、オプション #2 の方が魅力的になります。ユーザー ID はコア データであり、意味的にはユーザー ID から始めるのが理にかなっています。
  • ユーザー主導ではない機能を追加するつもりですか?/user/1234/update、/user/1234/chart、/question/45678/activity、/question/45678/stats など、ヘッダー ディレクトリを先頭に置くのが合理的かもしれません。

他のヒント

このスキームを使用すると、(行儀の良い) ロボットがサイトをスパイダーするのを簡単に阻止できます。

 http://< tld >/update/1234
 http://< tld >/chart/1234

これは、/robots.txt ファイルを設定して次の内容を含めることができるためです。

 Disallow /update/
 Disallow /chart/

私にとって、それは見落とされがちな素晴らしいボーナスです。

オプション #1 は、一般的な ASP.NET MVC の例に一致します。例の一部は次のとおりです。 モデルビューコントローラー モデルの形式は {controller}/{action}/{id} です。の ルーティングに関する .NET 3.5 クイックスタート いくつかの有効なルート パターンを示す表があります。

ルート定義 - URLの一致例

{controller}/{action}/{id} - /products/show/beverages

{table} /details.aspx - /products/details.aspx

blog/{action}/{entry} - /blog/show/123

{ReportType}/{year}/{month}/{day} - /sales/2008/1/5

{ロケール}/{アクション}
-- /en-US/show

{言語}-{国}/{アクション}
-- /en-US/show

私は個人的にこのスタイルが気に入っています。なぜなら、ユーザーを同じに保ちながら、ユーザーに対する具体的な洞察を提供できるからです。

  • http://< tld >/1234/update
  • http://< tld >/1234/chart

別の方法を選択した場合は、/update または /chart の下にあるものをすべて表示し、ユーザーごとに絞り込むことができると予想します。

後者を選択してください。URL は階層的であることを意図しています (少なくとも、ユーザーはローカル ディレクトリ パスと同様に URL をそのように読み取ります)。ここでの焦点は、特定のユーザーのさまざまなビューにあるため、「ユーザー」はより一般的な概念であり、最初に記述する必要があります。

質問に答えただけです 「URL ルートをどのように構築しますか?」 URL を RESTful、ハッキング可能、そしてユーザーフレンドリーにすることについての私の意見を述べます。この質問に同じようなことを書くよりもリンクした方が良いと思い、リンクしました。

コンテキストの観点からは、項目の代理キーの後にその項目が何であるかのコンテキストよりも、アプリケーションの後にパラメーターが続く方が、私にとってはるかに意味があることに同意します。最終的には、どちらがプログラムするのに自然であるかを提案します。

慣例ではオブジェクト/動詞/ID となっているため、次のようになります。

http://< tld >/user/update/1234

(更新された質問と一致することに今気づきました:)

はい、#3 が最良の選択です。

これは、あなたが言及したように非ユーザー操作 (stats/) だけでなく、マルチユーザー操作もサポートします。

http://< tld >/user/list/

ユーザーをリストする方法がある場合は、ユーザー セグメントを導入します。

http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart

自分自身の詳細のみを表示できる場合、つまりユーザーが相互に表示されない場合は、ユーザー ID はセッションから推測できるため、必要ありません。その場合は次のようになります。

http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top