3

フライト>座席>予約のようなリソース構造があるため、予約は特定のフライトに属する特定の座席に属します。

http://example.com/jdf_3prGPS4/1/jMBDy46PbNc
                   ----------- - -----------
                        |      |       |
                        |      |       |
                     flight  seat  reservation

顧客は後でキャンセルするためにこの（やや醜い）URLを取得するので、リソース構造を省略し、予約へのリンクを短くすることを検討します。 

http://example.com/reservation/jMBDy46PbNc

このURLを短縮しない理由（ユーザーに関連する）はありますか？

4

2 に答える 2

3

エンドユーザーは、URL構造が何であるかをあまり気にしません。実際、彼らがそこでどのように見えるかを考えると、彼らはほぼ確実にそれらを見たくはなく、代わりにクリッククリックするだけです。これは実際には機能上の考慮事項を残すだけです。

URLがまったく同じリソースにつながり、そのリソースが異なるURLでまったく同じように動作する場合、ほとんど定義上、どちらを使用してもかまいません。

唯一の本当の要因は、セキュリティへの影響があるかどうかだと思います。予約IDを推測できますか？それは私をどこにでも連れて行ってくれますか（つまり、私はまだログインする必要があるか何か）？座席とフライトもある場合、3つすべての有効な組み合わせを推測できる必要があります。これは、予約IDをブルートフォースするよりも明らかに困難です。

この最後が問題ではない場合は、長いURLを使用する理由はありません...

于 2012-01-04T11:36:11.897 に答える
3

長いURLと短いURLのどちらを提供するかは大きな問題ではありませんが、どちらか一方だけを提供するか、両方を提供するかは大きな問題です。両方のURLが同じコンテンツを返す場合、キャッシュ（サーバー側、中間、またはクライアント側）に重複する情報があり、特にそれらが異なる場所にキャッシュされている場合、これらは2つのリソース間で同期しなくなる可能性があります生涯。理想的には、どちらか一方を提供する必要があります。本当に両方を提供したい場合は、複製するのではなく、一方を他方にリダイレクトする必要があります。

于 2012-01-04T15:13:02.557 に答える