独自のID形式を使用する場合と比較して、（RESTのように）グローバルに一意のURIを使用してリソースを参照することの利点は何ですか？
例えば：
最初のアプローチでは、URL全体がIDです。2番目のアプローチでは、5つだけがIDです。2番目のアプローチに対する最初のアプローチの実際的な利点は何ですか？
なぜREST（そう思われる）が最初のアプローチを提唱するのに邪魔にならないのですか？
- 編集：
私の質問は、実際には2つの別々の質問をしたため、混乱を招きました。
私は自分の投稿を使用して、以下の両方の質問に回答しました。
そのような uri を見たときの主なことは、通常のユーザーがその uri を思い出すことができるということです。
私たちオタクはクエスチョン マークと get 変数で問題ありませんが、誰かがhttp://www.host.com/?view=users&name=johnではなくhttp://www.host.com/users/johnを覚えている場合、それは大きなメリット。
私は自分の質問に答えます：
1）URIが重要なのはなぜですか？
LeonardRichardsonとSamRubyによるRESTfulWebサービスから引用します（ISBN：978-0-596-52926-0） ：
「クラゲに関するリソースのディレクトリ」というジャンルのリソースに名前を付ける実際のURIについて考えてみます：http ：//www.google.com/search？q=jellyfish 。そのクラゲ検索は、 http：//www.google.comと同じくらい実際のURIです。HTTPがアドレス指定できない場合、またはGoogle検索エンジンがアドレス指定可能なWebアプリケーションでない場合、そのURIを本で公開することはできません。「google.comへのWeb接続を開き、検索ボックスに「クラゲ」と入力して、[Google検索]ボタンをクリックします。
これは学術的な心配ではありません。1990年代半ばまで、FTPサイトのファイルを記述するためにftp：// URIが一般的になると、人々は次のように書く必要がありました。「ftp.example.comで匿名FTPセッションを開始します。次に、ディレクトリpub / files /に移動し、ファイルfile.txtをダウンロードします。」URIにより、FTPはHTTPと同じくらいアドレス可能になりました。今、人々はただこう書いています：「ftp：//ftp.example.com/pub/files/file.txtをダウンロードしてください。」手順は同じですが、今では機械で実行できます。
[...]
アドレス可能性は、Webアプリケーションの最も優れた点の1つです。これにより、クライアントは元のデザイナーが想像もしなかった方法でWebサイトを簡単に使用できるようになります。
2）アドレス可能性の利点は何ですか？
サーバーが提供するURIを自分で作成するよりも、追跡する方がはるかに簡単です。これは、リソースの関係が複雑になりすぎて単純なルールで表現できないため、特に当てはまります。多数のクライアントでロジックを再実装するよりも、サーバーで一度ロジックをコーディングする方が簡単です。
個々のリソースURIが変更されていない場合でも、リソース間の関係は変更される可能性があります。たとえば、Googleマップがマップタイルの縮尺を変更した場合、相対的なタイル位置を計算するクライアントは機能しなくなります。
3）カスタムIDに対するURIの利点は何ですか？
カスタムIDは、リソースを一意に識別します。URIは、どこにあるかを示すことでさらに一歩進んでいます。これにより、クライアントロジックが簡素化されます。
主に検索エンジン最適化。
それはまた、彼らを覚えやすくし、私の意見ではよりクリーンでより専門的に見えるようにします。
1 つ目は、審美的に優れています。
技術的には違いはありませんが、できる限り前者を使用してください。
Ólafur が述べたように、以前の URL の明快さは 1 つの利点です。
もう 1 つは、実装の柔軟性です。
学生 5 がめったに変更されないとしましょう。REST スタイルの URL を使用する場合、コードを実行する代わりに静的ファイルを提供するオプションがあります。Rails では、students/5 への最初のリクエストで、Web ルートの下にキャッシュされた html ファイルが作成されるのが一般的です。そのファイルは、バックエンドに触れることなく、後続のリクエストを処理するために使用されます。当然のことながら、そのアプローチについてレール固有のものは何もありません。
後の URL ではこれが許可されません。静的ページの名前に URL 変数 (?、=) を含めることはできません。
どちらの URI も REST の観点からは有効ですが、Web キャッシュではクエリ文字列パラメーターの扱いが大きく異なることに注意してください。
キャッシュを有利に使用したい場合は、クエリ文字列パラメーターを使用してリソースを識別しないことをお勧めします。
風水の原則をどれだけ忠実に守りたいかということだと思います。