11

明確に定義されたRESTfulシステムでは、クライアントはルートURIまたはいくつかの既知のURIを知っているだけでよく、クライアントはこれらの初期URIを介して他のすべてのリンクを検出する必要があると言われています。私はこのアプローチの利点（分離されたクライアント）を理解していますが、私にとっての欠点は、クライアントが何かにアクセスしようとするたびにリンクを検出する必要があることです。つまり、次のリソース階層が与えられます。

/collection1
collection1
  |-sub1
    |-sub1sub1
 |-sub1sub1sub1
         |-sub1sub1sub1sub1
    |-sub1sub2
  |-sub2
    |-sub2sub1
    |-sub2sub2
  |-sub3
    |-sub3sub1
    |-sub3sub2

「クライアントはルートURIのみを知る必要がある」アプローチに従う場合、クライアントはルートURI、つまり上記の/ collection1のみを認識し、残りのURIはハイパーメディアリンクを介してクライアントによって検出される必要があります。クライアントがGETを実行する必要があるたびに、たとえばsub1sub1sub1sub1で、クライアントが最初に/ collection1でGETを実行し、返された表現で定義されたリンクをたどってから、サブリソースでさらにいくつかのGETを実行して、必要なリソース？または、接続性についての私の理解は完全に間違っていますか？

よろしく、Suresh

4

3 に答える 3

6

APIを使用しているユーザーエージェントのフローと一致しないRESTAPIを構築しようとすると、この不一致が発生します。

クライアントアプリケーションを実行するとき、ユーザーには常に初期画面が表示されることを考慮してください。この画面のコンテンツとオプションをルート表現と一致させると、使用可能なリンクと目的のトランジションがうまく一致します。ユーザーが画面上のオプションを選択すると、他の表現に移行できます。クライアントUIは、新しい表現を反映するように更新する必要があります。

REST APIをある種のリンクトデータリポジトリとしてモデル化し、クライアントUIを独立したトランジションのセットとしてモデル化しようとすると、HATEOASは非常に苦痛になります。

于 2010-07-14T16:03:29.133 に答える
4

はい、クライアントアプリケーションがリンクをトラバースする必要があるのは正しいですが、リソースが検出されたら、そのリソースへの参照を保持し、1つのリクエストよりも長い時間使用しても問題はありません。クライアントが物事を永続的に記憶する可能性がある場合は、そうすることができます。

Webブラウザがブックマークを保持する方法を検討してください。ブラウザにはおそらく10個または100個のブックマークがあり、ページの階層の奥深くでこれらのブックマークのいくつかを見つけた可能性がありますが、ブラウザはそれらを見つけるためにたどったパスを覚えていなくても、それらを忠実に覚えています。

よりリッチなクライアントアプリケーションは、sub1sub1sub1sub1のURIを記憶し、それでも機能する場合はそれを再利用できます。それはまだ同じことを表している可能性があります（そうあるべきです）。それがもはや存在しないか、他のクライアントの理由（4xx）で失敗した場合は、手順をさかのぼって、適切な代替品を見つけることができるかどうかを確認できます。

そしてもちろん、ダレルミラーが言ったこと:-)

于 2010-07-14T22:56:40.797 に答える
0

それが厳格な要件だとは思いません。私の理解では、クライアントがリソースに直接アクセスしてそこから開始することは合法です。重要なことは、状態遷移に対してこれを行わないことです。つまり、/foo1などを操作した後に/foo2を自動的に続行しないことです。最初に/products/ 1234を取得して編集すると、まったく問題ないようです。サーバーは、たとえば、/ shop / products / 1234へのリダイレクトを常に返すことができ、下位互換性を維持できます（これは、検索エンジン、ブックマーク、および外部リンクにも望ましい）。

于 2010-07-14T14:24:29.467 に答える