27

アクセス権に基づいて、異なるユーザーに対して同じ質問に対して異なる回答を提供したいと考えています。私はこの質問を読みました：

RESTful 応答でのプライベート データの除外

しかし、REST についての私の理解では、特定のリソースは特定の場所に存在する必要があり、関心のある情報の量に応じて複数存在する必要があるため、/people.xmlとの両方を提供する必要があるという受け入れられた回答には同意しません。/unauthenticated/people.xmlの。

私が設計しているシステムは、あのシステムよりもさらに複雑です。ユーザーが多数の友達のサークルを作成し、それらにさまざまなアクセス権を割り当てたとします。たとえば、私の「知人」サークルは私の誕生日にアクセスでき、「専門職」サークルは私の職歴にアクセスできるかもしれませんが、その逆はできません。私が言及した質問からの回答を適用するには、ユーザーのすべてのサークルを取得する方法が必要です (セキュリティ上の理由から秘密にしておく必要があるかもしれませ/circles/a/users/42ん/circles/b/users/42) /circles/c/users/42。結果をマージして、利用可能な最大量の情報を表示します。明らかに、他のサークルが取得するすべての情報を取得する単一のサークルが必ずしも存在するわけではありません。これは十分にトリッキーだと思います (おそらく、いくつかの種類のオブジェクトでこれを行う必要があり、将来のバージョンでは別の手順が必要になる可能性があることに注意してください) 。私のサークルのいくつかで？その問題も解決できますか？上記のクエリのいずれにも応答することを拒否し、回答を得ることができる新しいクエリを思いついたとしても、この特定のユーザーが個々のアクセス制限のために異なる方法で扱われているという事実が明らかになります.

ここで何が欠けていますか？RESTful Web サービスを開発することは可能ですか?

動作が RESTful ではないという結論が得られた場合、これは依然として REST 契約を破っても道徳的に問題ない状況として構成されますか? もしそうなら、マイナスの影響は何ですか？たとえば、プロキシ キャッシュの問題のリスクはありますか?

4

2 に答える 2

31

フィールディングの論文によると (それは本当に素晴らしい文章です):

リソースは、一連のエンティティへの概念的なマッピングであり、特定の時点でのマッピングに対応するエンティティではありません。

言い換えると、「要求しているユーザーの割り当てられたプロジェクト」として定義されているリソースと、その表現が の URI によってアクセスできる/projects場合、ユーザーに対してプロジェクトの 1 つのリスト (つまり、表現) を返すことによって、REST の制約に違反することはありません。 A と、ユーザー B が同じ URI を取得したときの別の (表現)。このように、インターフェースは統一/一貫性があります。

これに加えて、REST は明示的なキャッシュ命令を応答に含めることのみを規定しています。

キャッシュの制約では、リクエストに対するレスポンス内のデータが、キャッシュ可能またはキャッシュ不可として暗黙的または明示的にラベル付けされている必要があります。

それをどのように管理するかは、あなた次第です。

それを念頭に置いて、

統一されたインターフェースの制約に違反しない限り、特定のリソースの表現を要求するユーザーに応じて変化するリソースの表現を快適に返す必要があります。表現を返すために単一のリソース識別子を使用しないでください。さまざまなリソースの。

それが役立つ場合は、サーバーがリソースのさまざまな表現 (XML または JSON、フランス語または英語など) で応答することも考慮してください。応答して送信します。それがヘッダーセクションの目的です。

于 2012-09-21T21:32:49.873 に答える
2

他の解決策が正しくないように思われることに同意します。URL 構造が複雑になり、リソースを見つけるのが難しくなります。ただし、REST を適切に行った場合は、リソースの URL が何であるかは問題ではありません。サーバーがそれを制御するためです (そして、必要に応じて自由に再配置できます)。クライアントが本当に「REST」である場合、サーバーとの事前のネゴシエーションを通じて、必要なリソースを検出します。したがって、パスはクライアントにとって本当に重要ではありません。REST の原則に違反しているからではなく、使い方がわかりにくいので好きではありません。

しかし、それはおそらくあなたの質問には答えません-あなたが言及しなかったのはあなたのセキュリティ設定です-おそらく、リクエストヘッダーの一部としてリクエストでセッショントークンを渡しています。したがって、バックエンド処理には、特定の一連のセキュリティ制約に結び付ける機能が必要です。そこから、必要なビジネス ロジックを含むリストを作成し、セッションに関連付けられたユーザーのセキュリティに基づいて限られたリソースを返します。

アルゴリズム自体については、通常、許容可能なデータを応答にマージする最小または最大の制限型アルゴリズムを実装します (Java レルムまたは Microsoft のユーザー セキュリティ モデルに非常に似ています)。

制限されている場合と制限されていない場合でデータの構造が異なる場合、データの 2 つの異なる表現を作成し、ユーザーが表示を許可された方を返すことができます。とにかく、クライアントは受け入れられた MIME 応答タイプを要求する必要があり、要求ヘッダーのセッション セキュリティに基づいて異なる回答を提供するだけです。または、オプションの要素に表現を提供し、承認に基づいて適切な 1 つのベースに記入することもできます (ただし、これは私の意見では少しハッキーです)。

于 2012-06-20T04:59:44.963 に答える