2

Resource Oriented Architecture（ROA）で定義されているConnectednessの利点は何ですか？私の理解では、Connectednessの核心は、ルートURIのみを使用してアプリケーションの状態全体をクロールする機能です。

しかし、それは本当にどれほど役に立ちますか？

たとえば、HTTPGEThttp ://example.com/users/joeがhttp://examples.com/uses/joe/bookmarksへのリンクを返すと想像してください。

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

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

  2. なぜリンクを使用するhttp://example.com/users/joe/bookmarks/2方が優先されるのid="2"ですか？

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

4

3 に答える 3

1

Uris を変更することは望ましくありませんが、それは起こります。Uris を作成する代わりに完全な Uris を使用すると、変更の処理が容易になります。

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

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

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

リソース内のリンクは、ユーザーが何を選択できるかのプレースホルダーだと考えています。誰がどのように作業を行うかは、サーバーがそのリンクに添付する uri によって決まります。

于 2008-10-16T16:05:39.920 に答える
0

私は自分の答えを追加します：

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

拡張が容易で、小さなアプリやスクリプトを作成して、コア アプリケーションと連携して簡単に動作させることができます。

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

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

もちろん、全体の議論の反対側は、単純な UID システムよりも URI ベースのシステムを実装するには時間がかかるということです。しかし、あなたのアプリが他のユーザーによって定期的に使用される場合、その初期投資は大幅に回収されます (拡張性に基づく優れた ROI があると言えます)。

追加: ある程度好みの問題であるもう 1 つの点は、論理的で定義された意味を伝えるため、URI 自体がより適切な名前になることです。

于 2008-10-15T03:03:38.780 に答える