6

私が理解しているように、ハイパーテキスト駆動型のRESTful Webサービスを使用すると、クライアントは、いくつかのよく知られたエントリポイントを除いて、サーバーURIレイアウトについて何も知らないはずです。これにより、サーバーが独自のURIスペースを制御し、クライアントとの結合を減らすことができるようになります。

サービスのクライアントが新しいリソースを作成するための成功した要求を送信すると、サービスは201 CREATEDに応答し、新しいリソースにアクセスできるURIをLocationヘッダーフィールドに提供します。

将来、リソースへの直接アクセスを可能にするために、クライアントがこのURIを保存できるようにする必要がありますか？その場合、どのくらいの期間ですか？URIがクライアントによってキャッシュされている場合、これは、サーバーがURIレイアウトを変更するたびに、古いURIにアクセスしたときに永続的なリダイレクトが提供されるようにする必要がある状況を設定しているようです。そうでなければ、クライアントは壊れます。数年にわたって、このリダイレクトシステムは手に負えなくなる可能性があります。

この状況では、URIテンプレートを使用するREST-RPCハイブリッドアプローチよりも、サーバーがURIスペースをより細かく制御できるようにはなりませんでした。

表現のキャッシュについては多くの情報がありますが、ハイパーテキスト駆動型のRESTfulシステムでURIをキャッシュすることについてはどうでしょうか。

4

4 に答える 4

6

ティムバーナーズリーが言ったように、「クールなURLは変わらない」ことを忘れないでください。サーバーがURIをクライアントに渡すと、URIが変更され、誰かが古いものを要求した場合に備えて、（たとえば）Moved-Permanently応答を送信することにより、今後URIを機能させ続けることがサーバーの仕事になります。

これは、実際には、URIでリソースの人間が読み取れるプロパティを使用するのではなく、データベースIDやタイムスタンプに基づいて不透明なURIを設計することを多くの人に奨励するものです。人々が理解していることは何でも、彼らは変えたいと思うでしょう。

于 2009-08-19T15:57:36.297 に答える
2

はい、クライアントはURIの保存を許可されている必要があります。それが望む限り。Lickyが述べたように、スマートクライアントはMoved-Permanently応答を使用してブックマークを更新できます。

あなたがそれについて考えるならば、我々は可能な限り最高の状況を持っています。サーバー上のURLを変更しながら、選択した限り古いクライアントをサポートすることを選択できます。インテリジェントクライアントは、新しいURLに効果的に自動更新できます。

これらの古いURLをサポートし続けることを選択する期間は、実際には、既存のクライアントとそれらを維持できる容易さに基づいて行う必要がある決定です。

私にとって、これはRPCスタイルのインターフェイスのバージョン管理の問題を大幅に改善したものです。

于 2009-08-19T18:14:45.553 に答える
1

これは古い質問だと思いますが、ここに表示されている回答には、まだ対処されていないサブコンポーネントがあると思います。

サーバーからリソースを取得しているのではなく、リソースのREPRESENTATIONを取得していることに注意してください。リソース自体のプライマリ識別子が変更されたり、ホームに戻されたりする場合がありますが、リソースの作成時にクライアントに返された表現は、独立して有効である場合とそうでない場合があります。それはすべて状況の問題です。

例として、モデレートされたコンテンツアップロードシステムを考えてみましょう。ユーザーは、モデレーターが検討するためにコンテンツをアップロードできる場合があります。これにより、最終的にコンテンツがより多くの視聴者/市場に公開される可能性があります。最初のアップロード時に、サーバーは、そのコンテンツの表現に対して（たとえば）「users / {userid} / uploaded/{contentid}」に送信するURIで応答する場合があります。ある時点で、モデレーターはコンテンツを「フロントページ」に昇格させることを決定する場合があります。コンテンツのその表現は、「content/{contentid}」のURIで利用できる可能性があります。これにより、元のアップローダーが「users / {userid} / uploaded/{contentid}」のデータにアクセスできなくなることはありません。永続的なリダイレクトが必要であるとは何も言われていません。実際、リダイレクトがないのには十分な理由があります。ユーザーがコンテンツを削除することを決定した場合、コンテンツに対してDELETEを実行できる必要があります。ユーザーが自分の「アップロードされた」場所からコンテンツ表現に対してDELETEを実行することはおそらく非常に優先されます。ただし、アップロードされたコンテンツに対するユーザーの権利が取り消されることがサイトの条件で示されている場合（珍しいことではありません）、モデレートプロモーションプロセスでユーザー自身の領域からコンテンツを効果的に削除し、「永続的な移動」を引き起こすことが理にかなっている場合があります。

それは本当に完全に特定の状況に依存しています。キャッシュされたURIの有効性は、サーバーのポリシーに完全に依存します。少なくとも、無効なURI（以前は有効だった可能性があります）へのリクエストは、クライアントが探していたリソース（表現）を「再発見」できる応答（HATEOASと一致）を引き起こすはずだと思います。 ; 少なくとも、エントリポイントへのリンク。

于 2011-06-13T18:10:52.113 に答える
0

RESTの原則の1つはリソースがアドレス可能であるということであるため、クライアントが特定のリソースのアドレス（URI）を追跡することは完全に許容できるようです。リソースURIは、参照した「よく知られたエントリポイント」の1つである必要があります。

于 2009-08-19T15:53:08.333 に答える