接続性の利点は何ですか？

Question

リソース指向アーキテクチャ（ROA）で定義されている接続性の利点は何ですか？私が理解したように、接続性の核心は、ルートURIのみを使用してアプリケーションの状態全体をクロールする機能です。

しかし、それは本当にどれほど便利ですか？

たとえば、HTTP GET http://example.com/users/joe が返されるとします http://examples.com/uses/joe/bookmarks へのリンク。

>

あなたが愚かなWebクローラーを書いているのでなければ（そしてそれでも私は疑問に思うでしょう）、コンパイル時に各リンクの意味をクライアントに教える必要があります。つまり、クライアントは「ブックマークURI」がブックマークリソースにURIを返し、特別なブックマーク処理アルゴリズムに制御を渡します。単に一般的なクライアントメソッドに盲目的にリンクを渡すことはできません。とにかくこのロジックが必要なので：

1. クライアントが実行時にURIを把握するのとコンパイル時に提供するのとの違いは何ですか（ http://example.com/users/bookmarks ルートURI）？

2. http://example.com/usersを使用してリンクする理由/ joe / bookmarks / 2 は id =＆quot; 2＆quot; ？

よりも好ましい

私が考えることができる唯一の利点は、時間の経過とともに非ルートURIのパスを変更できることですが、これはキャッシュされたリンクを破壊するため、とにかく本当に望ましくありません。何が足りないのですか？

Answer 1

Urisを変更することは望ましくありませんが、それは起こります。Urisを構築する代わりに完全なUrisを使用すると、変更に対処しやすくなります。

もう1つの利点は、クライアントアプリケーションが複数のホストからリソースを簡単に取得できることです。クライアントがURIを作成することを許可した場合、クライアントは特定のリソースが存在するホストを知る必要があります。すべてのリソースが単一のホスト上に存在する場合、これは大したことではありませんが、複数のホストからデータを集約する場合は、より注意が必要になります。

最後に考えたのは、リンクの静的なネットワークと見なすことで、接続性の概念を単純化しすぎている可能性があるということです。クライアントがリソース内の特定のリンクが存在する可能性について知る必要があることは確かですが、そのリンクをたどることの結果を正確に知る必要は必ずしもありません。

例を挙げてみましょう。ユーザーがいくつかのアイテムを注文し、カートを送信する準備ができています。送信リンクは、実際に注文がローカルに配信されるか国際的に配信されるかに応じて、2つの異なる場所に移動する場合があります。おそらく、特定の値を超える注文には追加のステップを実行する必要があります。クライアントは、送信リンクをたどる必要があることを知っているだけですが、次に進むべき場所の知識をコンパイルしていません。共通の「次のステップ」を構築できます。クライアントが明示的にこの知識を持つことができるようにリソースのタイプを指定しますが、サーバーにリンクを動的に配信させることにより、クライアントとサーバーのカップリングを大幅に減らすことができます。

リソース内のリンクは、ユーザーが選択できることのプレースホルダーと考えています。誰が作業を行い、どのように行われるかは、サーバーがそのリンクにアタッチするURIによって決まります。

Answer 2

拡張が簡単で、小さなアプリケーションやスクリプトを記述して、コアアプリケーションと一緒にかなり簡単に作業できます。

追加：まあ全体のポイントは、コンパイル時にURIをハードコードされた方法でuidに変換する方法を指定しないという考えから始まります。代わりに、辞書または解析を使用してそれを行うことができます柔軟なシステム。

その後、誰か他の人がURI構文を変更することに決めた場合、その人はあなたのコアアプリケーションに触れることなくURIを翻訳する小さなスクリプトを書くことができます。別の利点は、企業のシナリオ内であっても、URIが論理的な他のユーザーである場合、元のアプリに触れたり再コンパイルしたりすることなく、システムを利用するためのマッシュアップを簡単に作成できることです。

もちろん、引数全体の反対側は、単純なUIDシステム上でURIベースのシステムを実装するのに時間がかかることです。しかし、他の人があなたのアプリを通常の方法で使用する場合、その初期投資は大幅に回収されます（優れた拡張性に基づいたROIがあると言えます）。

追加：好みの問題であるもう1つのポイントは、URI自体が論理的で定義された意味を伝えるため、より良い名前になることです

Answer 3

独自の回答を追加します：

1. サーバーが提供するURIは、自分で作成するよりもずっと簡単です。これは、リソースの関係が複雑すぎて単純なルールでは表現できないため、特に当てはまります。多数のクライアントでロジックを再実装するよりも、サーバーで一度ロジックをコーディングする方が簡単です。
2. リソース間の関係は、個々のリソースURIが変更されていない場合でも変更される場合があります。たとえば、Googleマップが画面の左上から右下に向かって0〜100のマップタイルのインデックスを作成するとします。 Googleマップでタイルの縮尺を変更すると、相対タイルインデックスを計算するクライアントが破損します。
3. カスタムIDはリソースを識別します。 URIは、リソース表現を取得する方法を識別することにより、さらに一歩前進します。これにより、Webクローラーなどの読み取り専用クライアントや、ビデオやオーディオファイルなどの不透明なリソースをダウンロードするクライアントのロジックが簡素化されます。